Usability, Feasibility, Strategy – All Check. Business Value? LOL, 404.
You did it.
You followed the sacred Product Trio rituals:
Usability? Check. Users can technically click the button without crying.
Feasibility? Check. Engineering didn’t need to sacrifice any weekends.
Strategy? Check. Product blessed the roadmap.
You shipped it.
And then... crickets.
Dead KPIs.
The cold, blank stare of a dashboard with no significant lift.
What happened? You checked all the boxes, right? Right…?
Here’s the uncomfortable truth: doing everything "right" doesn’t guarantee you built anything that actually matters. It just means you built something really efficiently and beautifully... that nobody needed.
Why this happens (and why it keeps happening)
Usability is important.
Feasibility is important.
Strategy is important.
But guess what? None of those things alone guarantee business value. You can craft the world’s most delightful UX flow for a feature nobody asked for. You can architect a backend so scalable it could power Mars colonies — for a product nobody wants. You can roadmap a quarterly plan so tight it could win an Olympic gold — for outcomes nobody cares about. Usability, feasibility, and strategy are necessary. They just aren't sufficient.
How the Product Trio is supposed to work
The concept of the Product Trio was introduced by Teresa Torres in 2021. This is a core collaboration model in modern product development — instead of working in silos, the members work together continuously to explore customer problems, generate solutions, and validate ideas ensuring products are both valuable to users and viable for the business. At the heart of great products is the Product Trio: product manager, engineer and the designer. Sounds simple. In theory.
In practice, it’s a three-person jazz band where everyone’s instrument can accidentally drown out the others if you’re not careful. Here’s the basic breakdown:
Product manager: owns the “why”. They make sure that the product adds value and the team is solving real problems that move the business forward.
Designer: owns the “how it feels and works”. They champion usability, user experience, and making sure people don't rage-quit your product.
Engineer: owns the “how it’s built”. They make sure it's feasible, scalable, and doesn't require sacrificing a small village of servers.
When it’s good, the trio works like this:
PM identifies an actual, painful problem worth solving.
A designer creates a solution users can love without a PhD.
Engineer builds it so it actually ships this decade.
They ideate, use multiple methods to focus on the real user needs (value- and assumption mapping, user journey, rapid prototyping for validation, etc.). Each discipline catches blind spots the others would miss. Each pushes the team toward outcomes, not just outputs.
When it’s bad, though… it’s just three people building slightly different versions of the same mistake, but very passionately.
The blank canvas moment
Sometimes, you’re not handed a fully baked spec. You’re handed a blank canvas and a vague cry for help, like: “We need users to upload receipts... somehow.” This is the moment where real product magic — and real risk — begins. The Product Trio steps up, not with answers, but with assumptions:
What do users actually need here?
What outcomes would define success?
Where could this go horribly wrong?
You ideate together. You sketch wild ideas on whiteboards and sticky notes. You discuss over feasibility and user flow. And then, crucially, you prototype quick and dirty. Not because you love chaos (although... maybe), but because speed beats perfection when you're still guessing. Each prototype is a little scientific experiment. Each validation session is a step toward less guessing and more knowing.
You kill bad ideas quickly, while nurture good ones carefully. You iterate until it hurts less.
Only after this cycle — after you’ve moved from “total guess” to “reasonable confidence” — do you lock in the feature for real development.
That’s when the real KPI journey starts.
How assumptions, prototypes, and KPIs connect
Assumptions aren’t bad. Staying married to wrong assumptions is bad.
When you start from assumptions and validate fast: your first KPIs are hypotheses, not commandments. Your first prototypes are bets, not certainties. The goal isn’t to be right immediately. The goal is to learn fast enough that by the time you hit production, you’re not gambling anymore — you’re investing. And that’s the real bridge between messy creative ideation and beautiful, nerdy, data-driven development: good product development isn’t art or science. It’s art into science.
So how do you turn an understood requirement — say, “users need to upload receipts” — into KPIs?
Define the real outcome, not just the task. What’s the value behind that task? Is it faster reimbursement? Improved trust? Reduced support queries? A requirement becomes meaningful only when tied to a user or business goal.
Hypothesize the user behavior that reflects success. If the goal is faster reimbursement, a potential KPI might be Time to Submission — how quickly users upload after their transaction. If it’s about trust, maybe Completion Rate or Support Tickets per Upload is a better fit. You're asking: what behavior would show us that this is working?
Prototype and simulate the value. Before writing production code, create a lightweight flow or mock version. Test it with users. Not just “do they complete it?” but do they complete it confidently, quickly, and with satisfaction? This qualitative insight hints at whether the KPI you chose is actually capturing the desired value.
Pressure-test the KPI. Ask hard questions: Is it measurable with our current tools? Can it be moved through design or product decisions? Would moving it actually indicate more value for users or the business? What would success look like in the data? If your KPI doesn’t pass these tests, it might not be the right one — yet.
Pair qualitative insight with quantitative validation. Track the KPI across a test cohort. Are users actually behaving the way you predicted? Do the numbers reflect the stories users told you in usability tests or interviews? If not, revisit the assumption — not the metric yet. You might still be solving the wrong problem.
Only after this cycle — understanding the requirement, hypothesizing a KPI, testing it in real workflows, and validating that it's tied to actual user value — do you move forward with confidence. That’s how a vague need becomes a meaningful signal. That’s how assumptions become investments.
So, how do we avoid the 404?
Short answer: measure the outcomes, not just the output.
Longer answer, the real stuff:
Design with metrics in mind. Design isn’t just about making things pretty. Before you touch Figma, know exactly which user behavior or metric you’re trying to move. Otherwise, you're just decorating.
Build feasibility around value, not just possibility. Engineering can build almost anything — but should they? Feasibility needs to be filtered through real user or business value, not just technical possibility.
Strategy needs a KPI spine. A roadmap without measurable outcomes is just a to-do list in a business suit. Every big plan needs a KPI backbone to prove it's doing more than just “feeling strategic”.
Test ideas like you test code. You wouldn’t push untested code to production. Same goes for ideas. Prototype fast, validate early, catch the bad stuff before it becomes an expensive failure.
The real talk: what this looks like in practice
It’s messy. It’s iterative. It’s full of awkward moments where someone (maybe you) has to raise their hand in sprint planning and ask: “Hey... what problem are we solving again?” It means pulling KPIs into early discussions, not slapping them onto a retro slide deck three months later like a guilty afterthought.
It’s about shifting from “Are we building it right?” to “Are we building the right thing, right?” In other words: are you actually create value…?
That’s nice, but what are these metrics?
Measuring business value isn’t about staring blankly at a revenue chart and hoping for a miracle. It’s about tracking the stuff that actually tells you if users care. Here are a few metrics that can help you to kick-off your data-driven value-adding process:
Activation Rate: did users find the value — or bail before you could even say "onboarding"?
Retention Rate: do they stick around, or did they ghost you after the first date?
Feature Adoption: are they using the things you proudly announced at the last all-hands, or did they miss the memo (and the feature)?
Net Promoter Score (NPS): would they recommend you to a friend, or would they rather not be associated with you at all?
Conversion Rate: are they paying up, or are you just generously funding their free trial habit?
Churn Rate: how fast are they running for the exit?
Time to Value (TTV): how quickly do users feel the magic — or do they need a map, a sherpa, and a pep talk to get there?
Support Tickets per User: how many fires are you putting out because your “intuitive design” wasn’t quite so intuitive?
Can the Product Trio discover value users didn’t ask for?
Yes — and they should. In fact, that’s one of their superpowers — turning unspoken needs into real, measurable outcomes.
We discussed in detail how important it is to not just involve the users, but also rely on them, as we want to satisfy their needs. Validating ideas with users is critical, but it’s only part of the puzzle. Users are great at revealing pain points, but they’re not always able to articulate the solutions they need — or imagine possibilities they haven’t seen before.
When the members of the Product Trio collaborate deeply, they don’t just respond to what users say — they uncover unmet needs, latent behaviors, and patterns hidden beneath the surface. Through methods like journey mapping, assumption mapping, or behavioral observation, the trio can spot gaps or inefficiencies users have normalized and propose solutions users didn’t even know to ask for.
This is where innovation lives — not in building exactly what was requested, but in identifying what truly solves the problem in a meaningful way. The key is to still validate those ideas with users, even if they originate from the trio. Insight + creativity + testing = impact.
Don’t ship to Nowhere
You can craft beautiful experiences.
You can build rock-solid tech.
You can dream up bold, brilliant strategies.
But the real magic happens when it all connects to something that matters — for your users, for your business, for your team.
When you chase real value, you're not just shipping features. You're building momentum, loyalty, and a product people actually care about.
It’s not about chasing KPIs for the sake of numbers. It’s about making sure all the love, sweat, and late-night brainstorming turns into something that lives out there in the real world. Get that right, and it’s not just success — it’s the kind of work you’re proud to put your name on.
And hey, if nothing else, it beats building a shrine to the world’s most beautiful unused features… #irony.
