Kill the Feature Factory: Discovery That Never Stops

You have a team that ships. Features go out on schedule. And still, half of them do not move the number you care about. That is the feature factory: busy hands, no proof the work mattered. The fix is not more speed. It is a habit of talking to users and testing ideas every week, so the work you ship is the work worth shipping. Leaders get this wrong when they treat discovery as a phase before delivery instead of a loop that runs alongside it.

The deep cut

• Discovery runs beside delivery, not before it. Andrew Miller's team ran dual-track agile so learning never stopped for a ship date.
• A trio without engineers is design guessing alone. Teresa Torres warns that when engineers skip discovery, design becomes the only voice for the user.
• Map opportunities before you pick solutions. Cezara Moisuc pairs the product trio with an opportunity solution tree to force that order.

Discovery is a loop, not a launch phase

The old model treats discovery as a gate you pass through once, then you build. That is where teams stall. The better shape keeps two tracks running at once: one for learning, one for building. Andrew Miller went from feature factory to continuous discovery in a year using dual-track agile and outcome-focused KPIs, not a bigger backlog.

Maria Skaaden frames continuous design as a different feel from sprint-to-sprint work. The point is steady contact with users, week after week, instead of a research burst that ends the day building starts. When the loop never stops, you catch a bad bet early, when it costs a conversation and not a quarter.

Three people who decide together

Discovery falls apart when one person owns it. The product trio fixes that: a product manager, a designer, and an engineer or architect making calls together. Vishnu S Pillai lays out how the trio drives development, with the PM on strategy, the designer on the experience, and the architect on what is buildable. Same room, same decisions, not a relay handoff.

The hard part is engineers. They often skip discovery and show up only to build. Teresa Torres argues for pulling engineers fully into the trio so design is not the lone voice for the user. Bring them into customer calls, not just planning. An engineer who hears the problem builds a better answer to it.

Problem space before solution space

Teams love jumping to solutions. It feels like progress. It usually is not. Tim Herbig structures discovery into six steps over six weeks, split cleanly between problem space and solution space, with stakeholder check-ins built in. Knowing which space you are in stops the room from arguing about a build before anyone agrees on the problem.

To force that order, Cezara Moisuc pairs the trio with an opportunity solution tree. You map the outcome you want, branch out the user opportunities under it, then hang possible solutions off each one. The tree makes the logic visible. Anyone can see why a solution exists and which problem it serves.

Small cycles, real measures

Once the loop and the trio are in place, the work becomes steady iteration. Anum Hassan lays out iterative design steps for continuous improvement: build small, measure, adjust, repeat. Short cycles beat big launches because you learn faster and waste less when you are wrong.

The measure has to change too. A feature factory counts outputs: features shipped, tickets closed. Continuous discovery counts outcomes: did the number move. Miller's team pinned their KPIs to outcomes on purpose. That one swap is what keeps a fast team from being a busy one.

Three questions for your team

• Are we in problem space or solution space right now, and does the room agree? Herbig's split only works if you name it out loud.
• Which of our current KPIs count outputs, and which count outcomes? Pick one output metric to retire this quarter.
• When did an engineer last sit in on a customer conversation? If the answer is never, that is your first move toward a real trio.