ONE THING TO TRY
Describe the person, the moment that gets difficult, the finished result, and what can stay manual. Test one complete loop with a real task before adding more features.
Start with the stuck moment
Before choosing software or adding another dashboard, follow one task through the business. In this episode’s fictional service business, the problem is knowing which quote needs attention and who should act next.
Build a complete useful loop
Make it possible to take a real request from arrival to a clear result. Decide deliberately what stays manual, including pricing or customer email, and account for the work people still do outside the tool.
Test an ordinary day
Try missing information, changed quotes, and unclear responsibilities with someone who will actually use the tool. Protect customer information and saved work even when the first version is small.
Try the four-sentence brief
Name the person who needs help, the moment that gets difficult, what should be different when the task is complete, and what can stay manual. Choose one sign of progress and test a real task before expanding the tool.
Links from this episode
Transcript
Start with the job
Hey friends, hope you're doing well. Welcome back to another episode of Think Then Make. And today we're talking about building the smallest useful thing. So you got to start with a job someone needs done and you decide you're going to build a tool for your business. I think we've all been there where we are sitting and dreaming about this idea of I want to build a tool. I want to build a CRM. I want to build the software. I want to build, build, build, build, do this service, do this thing. So you decide you're going to build a tool for your business. At first the idea is super simple and you need a better way to track something, hand something off or stop doing the same tasks over and over. Then you start thinking about everything the tool could become. This is what I call scope creep. It needs a dashboard, maybe a client portal. It should send reminders. If you're already building it, you might as well add reporting and somebody will probably ask for a mobile app because you've used this thing once. You're planning a whole software company overnight. I want to talk about what happens before that. How do you decide what is worth building and where do you stop with the first version? My starting point is a simple question. What is the smallest useful thing we can put into somebody's hands that actually works? Useful is doing a lot of work in that sentence. A tiny tool that doesn't help anybody isn't automatically a good first version and a large tool with a bunch of features doesn't become valuable just because it took a long time to make. The point is to find a complete job you can make easier, then build enough to learn whether you've actually made it easier. Okay. You can follow this without looking at a screen. We're going to use an imaginary service based business, walk through a process and finish with a short brief. You can speak into your phone. Here's kind of the map that we're going through.
Find the moment that gets stuck
So find the moment that keeps getting stuck. Our example business sends a quote to potential customers, nothing crazy. A person asks for some work, the business learns what they need and somebody prepares a quote. The owner says they need a better system. The sentence sounds clear until you ask what better means. Faster quotes, fewer mistakes, a clear handoff, fewer messages asking whether somebody already replied. Each answer could lead to a completely different thing being built. So before we talk about features, let's follow one request. A customer sends an email, someone reads it, they need a few details so they reply with questions. The customer answers, another person works out the price. Somebody sends the quote, then the team needs to know whether the customer accepted it. You can hear the handoffs. You can also hear where information might disappear. Suppose the actual problem is that nobody can tell who's waiting on who. Requests aren't necessarily difficult to price, but they do get buried because the next action is invisible. That's a way more useful problem statement than we need a better system. That's way more clarity in that process. Now we can clearly say, hey, the person responsible for quotes needs to see which request needs an action, who owns the action, and when they were last touched. Notice that we haven't chosen software yet. We haven't opened up Claude Code. We haven't done anything. We just talked. We made a decision. We could learn something with a shared list. We could build a small internal page. That format should follow the problem we found. So I got to describe what that complete loop looks like.
Build a complete useful loop
When people hear small first version, they sometimes imagine a screen with almost nothing on it. The size of the screen isn't the important part. The important part is whether somebody can complete a useful loop. For our quoting example, the loop might be a request arrives, someone takes responsibility for it, the next action then becomes really clear, the team can tell when it's done. That's enough to describe a meaningful first version. It might need a place to enter a request, an owner, a status, next action, a way to close that request. It might need a link to the original email so the team can find the full context, but it probably doesn't need a system that calculates every possible price on day one. If pricing isn't getting stuck, automating it just introduces new work without solving the problem that we're investigating. I think we've all done this before. We've added a feature that we think would be helpful, and no one asked for it. Or we thought about adding a system or process, and no one asked for it and actually made the whole thing more complicated. It probably doesn't need a customer login. If the customer already communicates comfortably by email, a new portal is just going to add more friction. Again, this is creating problems versus solving problems. A complete small loop lets somebody get from a real starting point to a real result. That gives you something to observe. An impressive collection of disconnected features can be harder to learn because nobody's actually finished the job with it. There's no clarity, there's no answers, there's no direction, which makes it chaos. If you've ever seen any of that, you know it can get chaotic really, really quickly and really, really fast. It's something you have to think through, and you have to process through, and you have to go through as you're walking through it. A couple pieces.
Decide what stays manual
Decide what will stay manual. I think this is a massive piece in what we do because if we decide what will stay manual, then there's another part of the first version that deserves an actual decision. What are people still going to do themselves? Leaving something manual can be sensible. It can also hide a broken process. The difference is whether you've chosen it deliberately and made it workable. In our example, a person might still create their quote in the document tool they already use. The new system could simply record that the quote was sent, and who needs to follow up. That isn't a failure to finish the software. It could be the boundary that makes the first version useful this week. But if every request needs someone to copy the same information to five places, you haven't solved the handoff by adding a sixth place. You've added another obligation. Be honest about the whole workflow. Ask what someone has to do before and after the new tool, not just when they're working inside that tool. Sometimes a feature will look super efficient on the demo screen, or in Claude, or in ChatGPT, or whatever tool you're using because the work that feeds into it has been left out of the demonstration. So imagine showing a beautiful quote dashboard that's only accurate if the owner spends an hour every evening updating it. That hour belongs in the decision about whether the system is useful. For the first version, write down the manual steps, who will do them, how often, how will they know if they're needed. If you can't answer, the manual part is still an assumption, and you haven't made a practical plan for it just yet.
Small scope still needs care
And small doesn't mean careless. I want to separate small scope from low standards. You can postpone a report. You can postpone a color theme. You can postpone a workflow that only happens once in a while. That doesn't mean you should be casual about who can see customer's information or whether a person's work gets saved. Those are two different things. The right basics depend on the tool. An internal quote tracker with customer contact details needs appropriate access. A tool that replaces a record relied on by everyone needs a sensible way to recover that record if something goes wrong, not just, oh, it's gone, it's missing, our bad. Those requirements belong to the job you're supporting. They aren't decorations you add once the product looks successful. So for a first test, you can sometimes reduce the risk by using example information, keeping the existing process available, or trying the tool with one small part of the team. What you shouldn't do is quietly make the test depend on something you haven't built and haven't told anyone about. The goal is to learn from use without creating an avoidable mess for the people helping you learn. That is one reason I like a narrow first version. A smaller promise gives you a better chance at understanding what you need to make reliable.
Test an ordinary day
So you got to test it with an ordinary day. Once the first loop works, it is tempting to test it with the cleanest example that you can find: you know it's the perfect client, the perfect request, the perfect thing. But you got to create a request with every field filled in, and you got to move it through the statuses in the right order. You close it. Does everything look great? That's useful, but it isn't enough to understand the work. Bring an ordinary day into that test. What happens when the customer hasn't supplied the information you need? What happens when two people think the other one replied? What happens when a quote needs to change after it was sent? You don't need to automate every exception immediately, but you do need to know whether a person can recognize the exception and decide what to do next. In our example, a simple status called waiting on customer might be super helpful, but it only helps if somebody knows which question the customer still needs to answer. So maybe the useful addition is a short next action note, not creating another dashboard. One sentence that keeps a real request from disappearing. You find that out by following the work. You don't find it out by counting how many features you've shipped. A good test includes the person who will actually use the tool. Give them the job. Let them try it. Watch where they pause. Ask to stay near their shoulder. Ask them to record a video. If you keep explaining where to click or what a label means, write that down. Your explanation is part of what the tool hasn't communicated just yet, and if they use a different route than you expected, get curious. They might have misunderstood the tool. You might have misunderstood the job, and sometimes with that, it's helpful because you can observe those pieces. Maybe the team can identify every open request without searching through separate inboxes. Maybe fewer requests need a second conversation just to work out who's responsible. Maybe the owner can hand off the queue without narrating each item. These are super practical signs of progress. They aren't universal measurements every business should adopt, but choose a sign that belongs to the problem you have.
Learn from use and feedback
Also, you've got to decide what would tell you the first version isn't helping. If people keep maintaining the old list but they don't trust the new one, that's worth understanding and asking. If the tool creates more copying than it removes, notice it. If nobody knows what a status means, fix the shared understanding before adding more statuses. I know it can be really hard to hear feedback. I know sometimes we put on the cap and we say, hey, I can handle the feedback, but after you've built something, if it's not valuable or providing work, it's a good start to ask two questions. One is, is this useful and is it helpful? Or what changes do I need to make to make it useful and helpful? You've got to try to separate the usefulness of the idea from your attachment to the current implementation. You might discover that the team needs clear responsibility, not new software. That can still be a good result because the aim was to improve the work, not just build a tool. You might also discover that a simple tool is enough. That's also a good result. You don't need to have a full CRM SaaS platform just for one simple process.
Give AI a useful brief
AI can make the brief more important and make it easier to get a first version in front of you. That makes the question of what you build more important, not less. If you ask for a dashboard before you understand the decision it should support, you can get a dashboard out quickly, but it's still going to have a bunch of problems. Before asking for code, describe the person, the moment, and the result. For example, a service coordinator opens the tool each morning. They need to see their quote requests that need attention for the day. Every request must have an owner and a clear next action. The first version can leave pricing and customer communication in the existing tools. That's a much more useful starting point than build me a CRM. That process navigates with the AI of what do I need to do. It gives you a way to review what comes back. Can the coordinator do the job? Is the next action clear? Are the details they need actually there? The brief also helps you say no to a feature that arrives looking impressive, but doesn't serve the job. That is very important. Fast building is useful when you know what you're trying to learn. Otherwise, you can create more things to maintain without creating more clarity.
The four-sentence exercise
You got to make sure your brief, you can say it out loud. Here's an exercise for after today's podcast that you're listening to. Choose one task in your business that repeatedly gets stuck. If you're building it for your other businesses, do the same process. Do not try to fix your entire business. Just one task. Speak four sentences into your phone or write them down when you're back at your desk. First, the person who needs help is who? Give a name to this person as well. Second, the moment that gets difficult is what? What gets difficult? Third, when the task is complete, what should be different? Number four, what can stay manual in the first version? For our example, those sentences could be our coordinator needs help. Quotes get stuck when nobody knows who should act next. A useful result is a shared view where each open request has an owner and a next action. Pricing and sending the quote can stay in our current tools for now. Read those sentences back. Can you picture the person doing the work? Can you recognize the finished task? Have you kept the first version small enough to test? Then choose one sign that would tell you it's helping and try it with a real task before expanding it.
Start small and learn
The smallest useful thing isn't always the quickest thing to code. It's the promise you can complete in somebody's real work and learn from very honestly. So start there. Let's get the next version grown out and built out from what you can learn rather than from everything you can imagine. Guys, I appreciate you listening today. If you have any questions, as always, feel free to reach out. We love that you guys are a part of this community. Feel free to check out our website for more resources. We got a ton of blog posts and more content. And as always, we are thankful that you guys are a part of this community. If you have any questions at all, reach out. Thanks so much.