How to Build Products That Actually Win Today?
The Product Research Triangle: Daniel Fallman's interaction design research framework can revolutionise your product development approach
👋 Hey everyone!
Welcome to Product Unshipped, Himanshu’s newsletter for builders, PMs, and anyone in tech who’s tired of the fluff and needs the frameworks, stories, and real talk to actually ship something great.
Today, we're diving deep into a concept that’s reframed how I (and plenty of great teams at Google, Slack and Swiggy) see product work: The Product Research Triangle, adapted from Daniel Fallman’s foundational model for design research.
Most Teams Get Stuck “Smart”
Here’s a weird pattern: the better the team, the more likely they are to get stuck going fast in place.
The designer does three rounds of research but never leaves Figma
The PM runs 100 interviews but never joins support for a full day
The engineer builds exactly what the data says, yet engagement plateaus
The big lie: You’re not building wrong, or too slow. You’re building in only “one mode of seeing.”
Hence the question arises?
How do truly great product teams structure their work to actually build what matters and not just keep treading water?
A few weeks ago, a PM friend shared something that's been bugging me ever since.
Their team had been tracking a nasty drop-off between login and OTP verification nearly 30% of users just vanishing.
They did everything the handbooks tell you:
user interviews about permission prompts,
copy tests,
funnel optimization.
Still, nothing moved the needle.
Then someone finally measured what was actually happening. The OTP page was an H5 implementation taking 8-10 seconds to load on mid-range Android devices.
Most users never even saw the login form. They weren't rejecting permissions they were staring at blank screens and bouncing.
Here's the thing that struck me: this wasn't a "bad team" problem.
They were doing user research.
They had analytics dashboards.
They A/B tested copy changes.
But they were trapped in what I now recognise as the single biggest product blindspot: getting really good at one way of seeing users while missing everything else.
This type of research-backed breakdown takes hours to put together: If you're finding value in Product Unshipped's systematic approach to product intelligence.
Hit the “Subscribe Now“ button for weekly learnings you can test next sprint. Over 15,000 PMs, founders, and growth leads read this for insights they can't find anywhere else.
The Problem with "Best Practices"
We've all been trained to follow the product management playbook:
Talk to users constantly
Let data drive decisions
Ship fast and iterate
Build what users actually want
Yet somehow, 80% of software features are rarely or never used. Teams burn months building exactly what users said they wanted, only to watch engagement flatline.
The frameworks that were supposed to prevent "build traps" and "feature factories" seem to be creating new ones.
The more I've studied this, the more I think the issue isn't execution; it's perspective.
Most product teams get incredibly sophisticated at their preferred research method while developing massive blind spots everywhere else.
Some teams live in user interviews but never use their own product under real constraints. Others optimize dashboards religiously but couldn't tell you how their signup flow feels on a slow connection.
Still others ideate breakthrough features in workshops but never validate them with actual humans.
The best teams I know don't just do research; they systematically rotate between completely different ways of understanding users.
There's actually a name for this approach, buried in a 2008 academic paper that explains why some product teams consistently ship hits while others ship duds.
This framework isn't new. In 2008, Daniel Fallman introduced the "Interaction Design Research Triangle" to help design researchers understand their discipline.
However, his insights extend far beyond academic research; they offer a powerful lens for understanding how modern product teams can create breakthrough innovations while staying grounded in real user needs and business constraints.
The Three Corners of Product Excellence
Imagine your product development approach plotted on a triangle. Each corner represents a fundamentally different perspective on how products should be created, validated, and improved.
Product Practice: Where Reality Meets Execution
At one corner lies Product Practice; the world of shipping features, hitting deadlines, and solving immediate customer problems. This is where product managers spend most of their time:
working with engineering teams,
negotiating with stakeholders, and
making the countless tactical decisions that turn ideas into reality.
Product Practice is inherently context-driven, particular, and synthetic.
You're not building products in general; you're building this specific product for these specific users with these specific constraints.
The measure of success is concrete:
Does it work?
Do customers use it?
Does it drive business results?
Teams operating primarily in this space excel at execution. They know how to navigate organizational politics, manage technical debt, and balance competing priorities.
They understand that perfect is the enemy of good, and they ship products that solve real problems for real people.
But Product Practice alone can lead to incremental thinking. When you're constantly focused on the next sprint, the next release, the next customer request, it's easy to lose sight of bigger opportunities or alternative approaches to the problems you're solving.
What I learned: You can get addicted to the high of shipping, but sometimes you wake up to see you’ve optimized for speed and missed the bigger risks (or the most interesting upside).
Strengths:
You’re solving real problems for real people, right now
Stakeholders aren’t left wondering when something will be done
You learn through actual user behavior (not just hypotheticals)
Weaknesses:
Risk of incrementalism: just building the next obvious thing
Easy to skip the step of asking, “Should we even build this?” or “Is there a bigger leap?”
Tip: If you suspect your team is living in Product Practice, ask, “When was the last time we worked on a problem that wasn’t already in our backlog?” If it’s been more than a quarter, you’re probably stuck.
Product Studies: The Foundation of Understanding
The second corner represents Product Studies; the analytical, research-driven approach to understanding users, markets, and product performance.
This is where teams step back from the immediate pressures of shipping to ask deeper questions about what works, why it works, and what patterns emerge across different products and user segments.
Product Studies is cumulative, distancing, and describing.
Instead of getting lost in the particulars of your current feature set, you're looking for universal principles, gathering data across multiple touchpoints, and building systematic knowledge about user behavior and product performance.
This perspective drives activities like user research, competitive analysis, data analysis, and market studies.
Teams strong in this area make decisions based on evidence rather than assumptions. They understand their users deeply, track meaningful metrics, and can explain not just what happened but why it happened.
However, Product Studies can become paralyzed by analysis.
While understanding is crucial, products need to ship.
Teams that over-index on this perspective often struggle with decision-making under uncertainty and may miss opportunities that require bold leaps rather than careful analysis.
Strengths:
Decisions become evidence-based no more “executive HiPPO guesses”
Patterns and root causes surface, not just one-off anecdotes
Weaknesses:
Analysis paralysis: Teams debate research findings but don’t act
Risk of optimizing for metrics at the expense of creative leaps
What works: If you're living in Studies mode, calendar a “Commit to Action” review at the end of every research sprint where the only acceptable output is a product, feature, or learning shipped to real users.
Product Exploration: Pushing the Boundaries of Possible
The third corner is Product Exploration; the visionary, experimental approach focused on discovering what could be rather than optimising what is.
Product Exploration is where you ask “What if?” and challenge not just features, but the category.
Product Exploration is idealistic, societal, and sometimes subversive. Teams operating in this space aren't constrained by current market expectations or technical limitations.
They're imagining alternative futures and building products that demonstrate new possibilities.
This is where breakthrough innovations emerge; not just better solutions to existing problems, but entirely new ways of thinking about user needs and product experiences.
Think of the first iPhone challenging assumptions about mobile interfaces, or how Slack reimagined workplace communication.
But Product Exploration can lose touch with practical constraints. Revolutionary ideas that can't be built, marketed, or adopted are just expensive experiments.
Teams that live too much in this space may struggle to ship anything that users can actually benefit from.
Strengths:
Enables true breakthroughs; invents new categories
Energizes teams and attracts top talent
Weaknesses:
Can get detached from business reality
Risky if you don’t know when to switch back to “Practice” or “Studies” mode
Recommendation: Reserve time (and budget) for pure exploration: Google’s 20% projects, or Amazon’s “Working Backwards” docs for products that don’t exist yet.
Real-World Examples: Triangle Work in Action
These OG platforms are big because they work in understand the essence of Product Managers of these “Three Corners of Product Excellence”…
Slack: Shipping What Users Didn’t (Yet) Ask For
Slack’s team had “Practice” internal chat tools for years. The leap was asking “What if we created a fun, delightful, public messaging product?” pure Exploration.
They validated with Studies (lots of usage research) but shipped early, learning along the way. Moving between corners was key.
Instagram: From Burbn to Simplicity
Started as a check-in app (Practice), user behavior study showed only the photo sharing got real engagement (Studies), so they pivoted (Practice), then explored photo filters and social features nobody realized they needed (Exploration again).
Diagnosing Your Team: Where Do You Live on the Triangle?
Let’s make this practical.
Quick Worksheet
List your last 10 shipped features. Classify each as Practice, Studies, or Exploration driven.
What’s missing? Is everything a backlog sprint? Are you running the same usability study, but never acting? Are all your brainstorms just gathering dust?
Pro-Tip: Share this worksheet with your team and see if everyone gets the same answers. If not, that’s the real discussion.
The Real Trick: It’s All About Movement, the real magic happens there
Fallman’s real insight (and my own hard-won lesson) is that greatness comes from moving around the triangle—intentionally.
Trajectories
Think of your work as a journey:
Start in Exploration mode (What’s possible?)
Move to Studies (What’s true? What do users actually do/need?)
Land in Practice (What can we really ship that solves a need right now?)
At Paytm, most of my wins moved through all three corners; sometimes in weeks, sometimes over years. The worst times? When we parked in just one corner and stopped moving.
We got to move, experiment, THINK and then FIND and then DO……WHAT MOVES THE NEEDLE. But never STOP……
Loops
The best product development isn’t “Research, then Build, then Launch, then Repeat”; it’s loops:
Fast, repeating cycles between ideas, evidence, and execution not linear phases.
This is how Netflix can ship recommendations tweaks weekly and keep running wild experiments for years.
Advanced: The Tensions that Define Each Edge
Here's where things get really interesting and where most teams get stuck. Fallman identified that the real magic (and difficulty) happens not at the corners, but along the edges of the triangle.
These edges represent fundamental tensions that every product team faces, whether they realize it or not.
Practice ↔ Studies: "Real" vs. "True" - The Evidence Paradox
This tension sits at the heart of every product decision. Fallman illustrates this perfectly with the QWERTY keyboard example: Research consistently shows that alternative layouts like Dvorak significantly increase typing speed after a short learning period.
The evidence is clear - Dvorak is objectively "true" in terms of efficiency.
But
QWERTY keyboards dominate the market because they're "real" - they work in the practical world where users expect them, manufacturers can sell them, and switching costs are enormous.
In Product Terms:
"True" = What research/data shows is optimal
"Real" = What actually works in your market context
Real Example: Your user research shows a redesigned checkout flow increases conversion 15% in testing. But when shipped, customer service complaints spike 300% because users can't find what they expect. The research was "true" but not "real."
How to Navigate:
Reality-check research: Ask "What are the switching costs?" and "How does this interact with user expectations?"
Build truth sensors into practice: A/B test controversial changes, embed researchers with feature teams
Use the Reality-Truth Matrix: Plot decisions on "How true according to research?" vs "How real in our current context?"
Practice ↔ Exploration: "Viable" vs. "Visionary" - The Innovation Dilemma
Can your team build big visions, but then reign them in to deliver on time and on budget?
Fallman describes this as the "dollar vs. sun" dimension.
The dollar represents commercial constraints - market realities, budgets, time to market.
The sun represents visionary thinking - ideals about how things should or could be, providing alternative futures.
The iPhone Example:
Viable side: Carriers wanted keyboards (BlackBerry was king), touchscreens were considered inferior for typing
Visionary side: Jobs imagined phones as primarily internet devices, not calling devices
The breakthrough came from holding both perspectives simultaneously - building something visionary that was still commercially viable.
How to Master This:
Time-box both modes: 70% viable/commercial, 20% visionary bets, 10% pure exploration
Create Vision Anchors: For every practical feature, ask "How does this move us toward our long-term vision?"
Build Viability Filters for visions: Define what would need to be true, simplest testable version, path to commercial sustainability
Studies ↔ Exploration: "Universal" vs. "Radically New" - The Knowledge Paradox
This is the most subtle but perhaps most important tension. This is about when to trust patterns in user research versus when to challenge those assumptions entirely.
Research excels at identifying universal patterns - what users consistently do, need, struggle with. But these patterns are based on current behavior in current contexts. They tell you about today's users, not tomorrow's possibilities.
The Social Media Example:
Universal (Studies): People wanted better ways to stay in touch with distant friends/family
Radically New (Exploration): Nobody asked for sharing mundane daily updates with hundreds of acquaintances
Facebook honored the universal need but implemented it in a radically new way research couldn't predict.
How to Navigate:
Distinguish needs from solutions: Research identifies underlying needs (universal), exploration imagines different solutions (radically new)
Study behavior, imagine experiences: Use research to understand what people try to accomplish, exploration to imagine completely different ways to accomplish it
Create "Future User" personas: Alongside current user research, develop personas for who users could become
How to Get Unstuck?
Stuck in Practice? (Shipping but not innovating)
Symptom: You're hitting your metrics but losing to competitors who seem more innovative
Prescription: Schedule exploration time, challenge assumptions, prototype wild ideas
Stuck in Studies? (Researching but not shipping)
Symptom: You have lots of insights but struggle to turn them into shipped products
Prescription: Set research-to-action deadlines, embed researchers with feature teams, ship imperfect solutions
Stuck in Exploration? (Ideating but not delivering)
Symptom: You have amazing ideas but struggle to make them viable
Prescription: Add business constraints earlier, prototype with real users, partner with implementation-focused team members
Stuck between corners? (Paralyzed by tensions)
Symptom: Endless debates about research vs. speed, vision vs. viability
Prescription: Make the tensions explicit, assign perspective champions, create structured decision processes
The Meta-Learning
The teams that win big don't avoid these tensions - they get comfortable dancing with them.
They develop the muscle memory to move fluidly between corners as situations demand.
They stop seeing "research vs. shipping" or "vision vs. practicality" as either/or choices and start seeing them as both/and capabilities.
How to Build a Team That Wins at All Three Corners
1. Make the Triangle Visual: Print it out, stick it on your wall, refer to it in every roadmap and retro.
2. Assign Roles, Not Just Tasks: For every major project, assign someone to champion each mode:
The Executor (Practice)
The Research Lead (Studies)
The Visionary (Exploration)
3. Reward Movement, Not Perfection: Celebrate when teams shift from one mode to another. “Our research sprint led to an exploration day that triggered a code hack” > “We completed our Jira tickets.”
4. Regularly Audit Your Balance: Have quarterly triangle reviews: What % of time did we spend in each corner? What’s missing? Did we actively move?
The Triangle Is a Mindset, Not Just a Model
This isn't just about building better products (though it does that).
It's about building the kind of product team that can consistently navigate the complex, ever-changing landscape of modern product development.
The kind of team that doesn't just ship features or conduct research or generate ideas - but moves fluidly between all three as the situation demands.
And in a world where the difference between good and great products often comes down to how well teams navigate these fundamental tensions, that might be the most valuable capability you can develop.
Every time you feel stuck too incremental, too theoretical, or too caught up in wild ideas, ask yourself:
Where have we been living?
Which corner needs a visit?
The triangle won’t magically fix every problem. (Nothing will. If there was such a thing, Lenny or Shreyas or Nikita would have found it by now.)
But
it will give you a language for the tensions you're already feeling and a framework for navigating them more intentionally.
Share this article with your team on your slack channels and whatsapp group so that your next roadmap, won’t just be a technical sprint because you need to give something to the engineers to work to escape your “imposter syndrome” but something meaningful that will change course of the product you are building.
Comment below or hit Reply if you are reading on email, and you might just see your story in a future edition.
What corner of the product triangle does your team habitually gravitate toward?
What’s stopped you from making the jump to another?
Have a wild success (or pain point) from cycling through all three?
Until next time, keep building, keep questioning, and most importantly keep moving IN MOVEMENT.
PS: Want a worksheet and team guide for running your first Triangle Audit? Comment with “TRIANGLE” and I’ll send you the template we use.
In Case You Missed It
If you found the Research Triangle valuable, you'll love → The Psychology Trick That Increases Retention by 63%; it explores how psychological ownership through co-creation complements the Practice Mode insights in this framework.
For readers interested in behavioral science integration, check out 8 Research Papers Every Product Manager Should Read; it provides the academic foundation that makes frameworks like the Research Triangle actionable.
Next week, we're diving into another counterintuitive principle: <it’s a secret>
See you then. :)
Subscribe to Product Unshipped for weekly, research-backed frameworks you can test next sprint. No fluff, just systematic approaches to product thinking that start with users.
Love the triangle
Good read