Decisions: Make the next decision easier
Matthew Hall in conversation with Ryan Mish, Operator Engineer at Runpoint.
Full video transcript. The walkthrough uses the fictional Halden Build Group and Kestrel CRM. The 24–48 hours discussed is a requested review window.

00:00 | Matthew Hall
Hey, it's Matthew, and I'm the co-founder here at Runpoint. We spend almost all of our
time trying to use AI to radically improve our clients' businesses. And how we actually
do that is that we embed really smart, really technical folks with great business sense
into those businesses. We call them operator engineers. And they identify problems, they
remove bottlenecks, they deploy agents, they automate workflows, they build a lot of
software. And so while we are constantly trying to improve the processes and the output
of our clients' businesses, we also spend use that same rigor on ourselves.

We want to be a radically better business ourselves, an agency or a consultancy that
couldn't have existed before this new age of AI. And so today, I'm really excited to
have this conversation with one of those operator engineers, Ryan Mish, who is one of
the earliest hires at Runpoint and has been doing some fantastic work building CRMs and
ERPs for a bunch of businesses. That's his specialty. But he's going to talk about a
tool that he made and that we use on all projects now called Decisions.

And it is meant to speed up that human part of building software, the reviews and the
judgment, where a project can really drag on because you need feedback from lots of
different people. In the old days, it would have a very linear process where it would go
through design review, architecture review, prototype one, iteration two, so on and so
forth.

And we've collapsed all of that into a single iteration cycle where all the parties and
all the personas and all the stakeholders that matter can actually engage with working
software, leave and have discussions about the decisions that matter in a format that I
think makes a lot of sense and makes that conversation a lot richer. So let's get into
it. Hello, Ryan. All right. Why don't you start by just introducing yourself? How long
have you been at Runpoint? What kind of projects you're working on these days?

01:46 | Ryan Mish
Hey, I'm Ryan. I'm an operator engineer here at Runpoint. And that means that I build
CRMs and ERPs for businesses that solve process problems in their business.

01:54 | Matthew Hall
All right, Ryan. At Runpoint, we question pretty much everything about the old ways of
building software. So obviously, we have AI write most of our software, but we have
operator engineers like yourself who are ultimately accountable for the work. And there
are a lot of things that AI has sped up in the software development process, but there
are a few where AI doesn't naturally solve the bottlenecks in judgment and in decision
making, etc. My understanding is you've tried or maybe have solved this with this new
tool that we're calling, what's it called? Decision?

02:27 | Ryan Mish
Decisions.

02:28 | Matthew Hall
Decisions. All right. Can you tell us a little bit about it, why we did it in the first
place and what it does?

02:31 | Ryan Mish
Absolutely. Decisions allows us to put high fidelity HTML mockups into a platform where
all of the stakeholders across your team are in there. Your VP of sales, your VP of
finance are right next to each other looking at this one mockup of what the finished
product should end up looking like. And they can leave comments and questions, discuss
with each other and with operator engineers like myself to collaborate on what the final
product is going to look like in a way that's much more interesting than a boring
specifications document.

02:59 | Matthew Hall
Amazing. Okay. I can't wait to see it. But can you tell us up front what is the old way
of doing this? So what we replaced?

03:07 | Ryan Mish
Yeah. So the old way of doing this would have looked like initially doing user stories,
persona mapping exercises, specification documents that might be 15 pages long that
describe every outcome and every problem that you're solving in the tool. And then you
dive even further into a data model or data mapping exercise that is a spreadsheet that
says this field is a dropdown with these values in it. And those are really tough to get
through, particularly when you have a stacked work day full of other things to focus on.

03:36 | Matthew Hall
Okay. I want to see it. Can you show it to us, walk through the demo, and then we'll
talk about the rest of the why afterwards?

03:42 | Ryan Mish
Absolutely. Yeah. Let's jump into it. So in this case, I have a demo company of Halden
Build Group, and we're working on their Kestrel CRM. It's been about three weeks, and
we're now working on the pipeline because sales was their priority. And I've gone
through a meeting or two with the client and with their sales teams to understand the
tools they're already using and what they want to change in their processes. Now I've
built the first HTML mockup that I'm sharing with all of the appropriate stakeholders
and sending it through the Decisions framework.

04:11 | Matthew Hall
Okay. So this is the first time they're seeing actual mockups, not just designs, but
working software of their new CRM?

04:18 | Ryan Mish
Exactly.

04:19 | Matthew Hall
So what decisions and feedback are you actually hoping to get from the client in this
instance?

04:25 | Ryan Mish
Yeah. So the first thing that I'm looking for, especially because this is the first
mockup that we sent them, is just their initial reaction. What do they like about the
layout, about the fonts? Is it intuitive? Is it not intuitive? And then particularly on
a screen like this, I'm wanting to know, am I surfacing the right data here? Is this
what you're going to need at a glance in your weekly meeting that you have and your
monthly meeting that you have? Does it fit each of the personas that are in here?
Because it's not just sales that might look in here. It might be your executive
leadership team. It might be your finance team.

And they all need to see their own information surfaced in a way that's intuitive for
everybody.

04:58 | Matthew Hall
Okay. So I'm seeing a countdown clock in the top right. I'm seeing a number of
approvers. Can you talk me through how this actually speeds up review and decision
making?

05:10 | Ryan Mish
Yes. So as everyone knows, if you've ever sent a message to a large Slack group chat
that has 12 or 15 people in it and asked a question, there's not enough pressure to
actually answer the question. Everyone feels like, well, there's a number of other
people that can respond. So I don't have to. So what this does is we nicely, politely,
diplomatically apply a little bit of pressure to your team to say, to continue our
momentum that we like to have here at Runpoint, we need a response in 24 to 48 hours on
whatever the problem that we're looking for is.

So in this case, we're looking for approval on the information that's displayed in these
cards, in the rough layout, in the stages that we have selected. And so we invite the
appropriate approvers to review. They get an email and they get notifications as the
timer goes down. They can leave pins on it and then they can discuss with each other. So
Dana and Morgan are talking to each other here about what's the correct change to the
title that should be listed on this board. And then we also ask specific questions based
on these mockups.

So here we're wanting to know, can each stage be understood or what risk signal should
be the most prominent before that weekly call that they're going to be having. And
everyone can see each other's, everyone can see each other's responses to these
questions. So they make sure that they're on the same page. And then we request just a
final response. Is it approved? Do you require changes or do you not want to approve and
schedule some more time for us to understand where we may have gone?

06:29 | Matthew Hall
Is part of what we're doing here democratizing feedback? Because I can, I see a lot of
technical and non-technical reviewers here. And in the old world, you know, all design
decisions would go through design department. All technical decisions would get routed
to the single technical party. But those decisions would have long lasting impacts on
user roles and permissions, on what we're calling fields and all that kind of stuff. And
even more so, if we are replacing SaaS, you're just beholden to whatever conventions,
you know, the SaaS provider has already decided for you. Is that part of the goal as
well?

07:03 | Ryan Mish
Absolutely. The most important thing here is to get every persona and every stakeholder
that should be involved in this process involved as early as possible. Because the thing
that we don't want is to get to the end of the process and realize that we've left out
an important group that has their feedback that they want to see reflected in the app as
well. And particularly, it's to foster conversations between those different
stakeholders so that they're understanding each other's goals out of the software
instead of competing for only one group to be represented in the final product.

07:32 | Matthew Hall
Great. Can you give me a sense for the client experience? In what ways this is better
for the client working with us as opposed to the old days?

07:45 | Ryan Mish
So I'd say the biggest change compared to the old days, which I love referring to them
as that, I think that's kind of funny, is that you have a much shorter cycle of when you
can expect your revisions to come through. Because in the old way, you'd go through your
specifications gathering, you'd make your data model, and that would inform or kind of
be at the same time as your Figma designs and mockups were being created. But those were
just fancy drawings. They weren't something that you could click around or that you
could expect the animations to look exactly as the way they would in the final code.

08:14 | Matthew Hall
And then you don't know what the implications were of that decision you made in week
two, because you didn't understand it, right?

08:19 | Ryan Mish
Yeah, well, something else that's really cool here is these reviews aren't only just
weekly, and they're not just static reviews. So oftentimes, in practice with the tool,
someone will leave me a comment that is obvious in retrospect. So I go and I make that
change to the mockup, and then I re-import it here, leave a comment saying that it's
fixed, and then mark that comment as resolved. So you can see those changes even across
the 48 hours of this review cycle that we're working in that happened really, really
quickly.

08:44 | Matthew Hall
All right, very cool. So put a button on this for me. What is the business impact of
this Decisions tool?

08:51 | Ryan Mish
Yeah, the obvious one is shorter timelines and interdepartmental coordination. So when
we have all the right people in the room that are all talking with each other and
working with us here at Runpoint, we can make decisions much more efficiently, and we
can work much faster. But it's not just that. It's also involving more non-technical
people in what used to be a technical process. So when they feel empowered to drop a pin
and have a conversation about why something looks the way it does, as early in the
process as this is, the final product ends up being much better fitted to the team.

09:21 | Matthew Hall
Perfect. All right. Thanks a lot, Ryan.

09:24 | Ryan Mish
My pleasure. Happy to be here.

09:25 | Matthew Hall
All right. See ya.