7 Iterative Steps to Build the Right Features, Not to Just Ship Fast!

You know that feeling when you're building something, putting in all this effort, feature after feature. But you've got this nagging doubt, like, are we actually making things better for people? Oh, absolutely. It's that pressure, right? Yeah. It's like you're sprinting super fast, but maybe, just maybe, in the wrong direction. That tension between just shipping quickly and, you know, making a real impact is common. It really is. We end up focusing so much on what the features we sometimes lose sight of, the why. Exactly. And things can get a bit, well, messy. Well, if any of that sounds familiar to you listening, you're definitely in the right place today. We've been digging into this really interesting piece. It's called Seven Iterative Steps to Build the Right Features, Not to Just Ship Fast. Right, by Giant Chain. Yeah. And it draws heavily on Teresa Torres' work, too. Yes, continuous discovery habits, which is fantastic. So our mission here is to basically unpack these ideas. We want to pull out the actionable stuff, you know, like a cheat sheet for building better products by really getting your users. Focusing on those user needs, continuously learning. Exactly. We're going to look at seven key steps from the team setup right through to iterating after launch. Sounds good. Okay, so let's dive in. Step one, building a product trio. What's the core idea there? So the product trio. It's your product manager, a product designer, and crucially, an engineering manager working super closely together. Okay. Three key roles. Yeah. And the magic really is bringing those three viewpoints together right from the get-go. Ah. So not in sequence, but together. Precisely. The PM is focused on, let's say, the business value, understanding the user's problem, the designer champions the user experience, making it usable, maybe even delightful, and the ink manager. They're ensuring feasibility. Like, can we actually build this? Is it scalable? It's like different lenses on the same target, so you avoid building something cool nobody wants. Or something useful that's impossible to build reliably. Right. You've got built-in checks and balances, left guesswork from just one perspective. Spot on. Yeah. And you cut down on those painful handoffs and, you know, the misunderstandings that often happen later. Yeah, those can really kill momentum. It builds this shared understanding, this collective ownership. It's really foundational. okay that makes a lot of sense foundational so step two then weekly customer interviews weekly sounds uh intense it can seem like a big time commitment yeah why not just do like bigger research studies less often what's the payoff for weekly well the value of that weekly rhythm is the consistency yeah it's a direct ongoing line to your users actual reality think of it less like um formal, big R research, and more like regular, maybe informal, check-ins. Okay, less pressure, maybe. A bit, yeah. You're not trying to get statistically significant data every week. You're gathering rich, qualitative stuff about their experiences almost in real time. So you catch things quicker, like shifts in needs or new frustrations. Exactly. Things that lagging metrics won't show you for weeks, maybe months. And you can validate your own assumptions really fast before you sink a ton of resources into something. Ugh. So it's like constantly adjusting the rudder on a ship, tiny adjustments, instead of realizing you're miles off course and having to yank the wheel. That's a great analogy. It keeps you nimble, lets you course correct gently. Okay, I see the value now. And those chats feed right into step three, right? Seeking out user experiences and pain points. Yes, and this is a really key distinction the article makes. It's not about just asking users what features do you want. Right, because often people ask for solutions based on what they already know or what seems possible now. Exactly. You might get incremental improvements, but maybe miss the bigger picture. So the product trio needs to dig deeper. Like, what are the real struggles, the obstacles? What are they fundamentally trying to do? Where's the friction in their current process? If you focus on that, the underlying pain, you unlock so much more potential for, well, genuinely innovative solutions. The classic faster horse problem. People ask for a faster horse. when what they really need is a better way to travel. Understanding that core need, getting from A to B faster, opens up cars, trains, planes, a whole different solution space. So you're defining the problem really well first, not just jumping to solutions based on surface-level requests. Precisely. It's about correctly framing that problem statement. Okay. And that leads us nicely into step four, defining the outcome, not just the output. Big difference here, right? Huge difference. And it's easy to get caught up in outputs. What are outputs, just to be clear? Outputs are the things you make. The features you ship, the reports, the tasks you complete, tangible stuff. Easy to count, easy to show you're busy. Right. But they don't inherently guarantee value. Shipping 10 features, that's output. Doesn't mean users are happier or more efficient or stick around longer. Not necessarily. That's the outcome. Exactly. An outcome is a measurable change in user behavior that drives some kind of business result. Like, did engagement go up? Did users complete a task faster? Did churn decrease? So you could be busy shipping outputs all day long. But achieve absolutely zero meaningful outcomes. You're just spitting your wheels. Anchoring to outcomes forces you to ask, is this work actually going to change something important? Yes. It ensures your effort is creating real value. Okay, powerful distinction. So we've got our trio. We're talking to users weekly, uncovering pain points, focusing on outcomes. How do we organize all this to decide what to tackle? Step five, opportunity solution trees. OSTs. Right, the OST. It sounds a bit complex, but it's actually a really helpful visual tool. How does it work? Well, you start with your desired outcome at the top, the thing you want to change. Then branching down from that are the opportunities. These are basically the user needs, the pain points, the desires you've uncovered through those interviews. The things that if you address them would help you achieve that outcome. Exactly. They're linked. And then for each opportunity you decide to focus on, you brainstorm potential solutions. Different ways you could potentially tackle that specific user need. So it connects the docs visually. Outcome, opportunities, potential solution. And the article highlights focusing on one leaf level opportunity at a time. That means a really specific, well-defined problem lower down the tree. So you don't try to boil the ocean. Pick one specific thing. Right. It gives you focus. Makes progress measurable. It stops you from just randomly picking features off a backlog. Everything is tied back to a user need and that target outcome. Provides a clear rationale. A roadmap with reasons. You got it. Clarity and alignment. So once you've used the OST to pick a promising opportunity and maybe brainstorm some solutions, step six kicks in. Which is developing solutions and, crucially, validating them through testing. Yes. This isn't about just picking one solution from the tree and building the whole thing. No, it's more iterative, right? Small tests first. Absolutely. You take those potential solutions for your chosen opportunity, maybe you shortlist a few based on insights or data you have, and then you test them quickly and cheaply. Think rapid prototypes, maybe usability studies. Let them in front of users again, those weekly interviewees. Perfect candidates. You might do quick A-B tests if it makes sense, but the core idea is getting feedback before you commit significant engineering effort. Learning fast. Learning fast. Reducing risk. You're not aiming for a perfect, polished thing at this stage. You're gathering evidence. Does this idea seem like it will solve the problem? Will it move us towards our outcome? It's like running mini experiments. Get signals early. Adjust. Avoids that big, painful, we built it and nobody came scenario. Totally. Saves a huge amount of wasted effort and, frankly, heartache. Okay. So we test, we validate, we build something based on that evidence, then we ship it. But it doesn't end there. Nope. That brings us to the final step. Step seven. Iterating based on how your North Star metric evolves. The North Star. That main outcome metric we're tracking. Usually, yes. Or key metrics related to it. You've released your feature or improvement out into the wild. Now you watch. What happens? Monitor the data. Listen to feedback. Exactly. Did it have the impact you expected based on your tests? Are users behaving differently? Are they finding new issues? So launch isn't the finish line. It's just the start of the next learning loop. Precisely. The data you get post-launch, the ongoing user feedback that all feeds back into your understanding. Maybe it refines the opportunity. Maybe it suggests tweaks to the solution. Maybe it points to a whole new opportunity. It's a continuous cycle. It really is. Discover, deliver, learn, repeat. And as the article notes, Teresa Torres' book, Continuous Discovery Habits, is just packed with examples of this cycle in action. Really worth a read if you want to go deeper. Paperback, Kindle, it's out there. Sounds like a powerful framework, shifting away from just, you know, churning things out. It is. It's a shift from shipping fast to learning fast and building the right things as a result. So if we were to boil it all down. The real takeaway is that building great products isn't some frantic rush. No, it's much more intentional. It's this thoughtful, continuous process. Understanding users deeply, focusing on outcomes, and iterating based on learning. And those seven steps, we covered the trio, the weekly interviews, focusing on pain points, outcomes over outputs, the OSTs, testing solutions, and iterating post-launch. They give you a concrete way to actually do that. A practical framework. Each step. plays its part in that cycle of building better stuff. Okay. So here's something for you, the listener, to maybe think about. Mull it over. Consider your own work. It doesn't have to be product development. It could be anything where you create things for others. How might adopting even one of these steps change things? Maybe just starting with really digging into the underlying pain points, not just the surface requests. Yeah. What impact could that have? It's that shift in mindset, isn't it? From just doing things to trying to continuously do the right things, something to chew on.

Building great products requires a deep understanding of user needs and continuous iteration on solutions. In her book ‘Continuous Discovery Habits’, Teresa Torres outlines a process that a product trio — comprising a Product Manager, Product Designer, and Engineering Manager — can follow to integrate continuous learning into the product development lifecycle. By doing so, teams can stay aligned with customer needs while minimizing risk and fostering innovation.

Article: https://thepmshelf.blogspot.com/2025/03/continuous-discovery-habits.html

Book: https://amzn.to/434MvVv