Problem
The team was evaluating whether more content would improve adoption, but discovery showed that users were struggling to fit the product into their existing workflows.
Back to Product OS
Product Story
Why We Stopped Building More Content and Started Building Better Workflows
I thought we had a content problem. We actually had a workflow problem.
Key Takeaway
I shifted the product conversation from adding more content to improving the workflows that made existing content useful, discoverable, and easier to adopt.
Executive Summary
The decision in one page
Decision
I recommended shifting the product direction from content expansion to workflow improvement, using customer discovery to validate where friction appeared.
Outcome
The roadmap conversation became more focused on adoption behavior, user jobs, and workflow integration rather than content volume alone.
Business Impact
The decision helped protect product investment from scaling output before the team understood the conditions required for users to adopt and reuse the product.
The Product Problem
More content was not the same as more value
The obvious answer was to build more. More content looked like progress because it was visible, measurable, and easy to explain. But in discovery conversations, the stronger signal was not that users lacked content. It was that they had trouble turning content into part of their day-to-day work.
That distinction mattered because the roadmap could have spent another cycle increasing supply while leaving the adoption problem untouched. If users could not find the right material at the right moment, trust it quickly, and use it inside their workflow, adding more content would only make the library bigger.
As a Senior Product Manager, I saw the decision as a risk question: were we solving the customer problem, or were we scaling the artifact that was easiest for the organization to produce?
Product Context
Product & Users
Product
The product experience depended on customers discovering, evaluating, and applying specialized content in moments where they already had established habits, constraints, and decision routines.
Users
Users were not simply browsing for information. They were trying to complete work, teach, research, plan, or make progress inside an existing workflow with limited time and attention.
Business
The business needed product adoption and engagement to improve, but the discovery work suggested that adoption would depend on usefulness in workflow, not only breadth of available content.
Options Considered
Three ways we could have responded
The hard part was not choosing between good and bad ideas. It was deciding whether the team should keep scaling content supply or pause long enough to understand why adoption was not following the content investment.
Option A
Keep expanding content supply
Continue investing primarily in more content, assuming that a larger library would create more reasons for customers to adopt and engage.
Trade-off: Fast to justify and easy to measure, but it risked increasing volume without addressing why users were not turning available content into regular workflow behavior.
Option B
Improve discovery and packaging
Make the existing content easier to browse, evaluate, and present, without changing the underlying workflow assumptions.
Trade-off: Lower disruption and useful as an incremental improvement, but it could still leave the core workflow gap unresolved.
Option C
ChosenReframe the product around workflows
Use discovery evidence to understand where users were trying to apply the product, then shape the roadmap around workflow fit rather than content volume.
Trade-off: Required more alignment and a slower initial decision, but it gave the team a better chance of improving durable adoption.
Decision Framework
How I evaluated the path forward
I evaluated the options against customer evidence, business value, implementation cost, speed to learning, and strategic fit. The strongest option was the one that changed what the team learned, not simply what the team shipped.
Customer Evidence
5/5
Business Value
4/5
Implementation Cost
3/5
Speed to Learning
4/5
Strategic Fit
5/5
Adoption Signal
Customer Discovery
Workflow Friction
Roadmap Reframe
Product Direction
My Role
What I owned in the discovery decision
I owned the product framing: turning a broad adoption concern into a sharper question about whether users needed more content or a better way to use the content inside their existing workflows.
I influenced the roadmap conversation by bringing the team back to customer behavior. I looked for evidence of where users hesitated, where the product failed to fit their job, and where more supply would not remove the friction.
I measured the quality of the decision by whether it changed our assumptions. The goal was not to produce a discovery document. The goal was to help the team make a better product decision before committing build capacity.
My Decision
One Decision That Changed the Direction
I recommended that we stop treating the problem as a content-volume gap and instead investigate the workflow moments where users were deciding whether the product was worth adopting.
That changed the direction of the work. Instead of asking, 'What else should we add?', I pushed the team to ask, 'Where does this product need to fit into the user's day for adoption to become natural?'
The decision was uncomfortable because content expansion felt tangible. Workflow improvement required more interpretation, more prioritization, and more alignment. But it was the more honest product decision because it matched what discovery was telling us.
Alignment
Working Through Disagreement
Content momentum
Some stakeholders naturally saw content expansion as the safest path because it was visible and familiar. I reframed the discussion around whether more content would actually change user behavior.
Customer evidence
I grounded the discussion in discovery signals: how users described their work, where they encountered friction, and what would need to change for the product to become part of their routine.
Roadmap focus
The alignment shifted from debating output to clarifying the product job: help users move through their workflow with less friction, not simply give them more things to choose from.
Execution
How discovery moved from signal to product direction
01
Name the assumption
I made the content-volume assumption explicit so the team could test it instead of quietly building around it.
02
Listen for workflow signals
I reviewed customer discovery through the lens of user jobs, decision moments, and places where the product struggled to fit existing work.
03
Map the opportunity
I translated the discovery signals into opportunity areas so the team could compare workflow problems rather than jump directly to solutions.
04
Reframe the roadmap
I pushed the roadmap discussion toward workflow adoption, discovery quality, and moments of repeated use.
05
Connect artifacts to decisions
I used the discovery memo and opportunity framing to show how evidence changed the product direction before build work began.
Results
What changed after the decision
Business Impact
- Protected product investment from scaling content output before validating whether content volume was the true adoption constraint.
- Created a clearer strategic link between product engagement, customer workflow fit, and the roadmap choices the business needed to make.
Behavioral Impact
- Shifted the evaluation of success from availability of content to whether users could integrate the product into their existing way of working.
- Made customer behavior, workflow friction, and repeat-use moments central to the product conversation.
Product Impact
- Reframed the product direction around workflow improvement instead of content expansion alone.
- Established discovery artifacts that connected customer evidence to prioritization, opportunity mapping, and future product scope.
Reflection
What I learned
What worked?
Making the hidden assumption visible worked. Once the team could see that we were assuming more content would solve adoption, it became easier to test whether that assumption matched customer behavior.
What surprised me?
The surprising part was how reasonable the wrong answer looked. More content was not a bad idea in isolation. It was just incomplete because it did not address the workflow friction that made adoption hard.
What would I do differently today?
I would formalize the workflow map earlier. The sooner the team sees the customer's real sequence of work, the sooner product decisions can move from feature supply to behavior change.
Principle System
Product Principle
Customer Discovery
Users don't adopt products because they understand them. They adopt products because those products become part of the way they already work.
Discovery only becomes useful when it changes the product decision. In this case, the discovery work moved the team from adding more content to improving the workflow around how users found, evaluated, and used content in their real jobs.
View related storiesEvidence Library
Supporting Evidence
Artifacts that connect the narrative to product decisions, trade-offs, and operating evidence.
Evidence Quality: Some artifacts are representative reconstructions created to demonstrate product thinking while respecting confidentiality.
Discovery Notes
Discovery Memo
Preview
Representative artifact — to be published. Discovery synthesis capturing the shift from content-volume assumptions to workflow-friction evidence.
Representative discovery memo planned for publication while respecting confidentiality.
View artifactOpportunity Solution Tree
Opportunity Solution Tree
Preview
Representative artifact — to be published. Opportunity map connecting user outcomes, workflow opportunities, solution paths, and validation steps.
Representative opportunity solution tree planned for publication while respecting confidentiality.
View artifactUser Interview Summary
Customer Interview Summary
Preview
Representative artifact — to be published. Interview themes, workflow pain points, and adoption signals.
Representative interview summary planned for publication while respecting confidentiality.
View artifactExperiment Plan
Workflow Validation Plan
Preview
Representative artifact — to be published. Validation plan for testing whether workflow improvements would create stronger adoption behavior.
Representative experiment plan planned for publication while respecting confidentiality.
Product Metrics Dashboard
Adoption Behavior Dashboard
Preview
Representative artifact — to be published. Dashboard for tracking workflow adoption, engagement quality, and repeat-use signals.
Representative dashboard planned for publication while respecting confidentiality.
Related Capability
Customer Discovery bundle
Framework
Product Discovery
The framework behind validating product direction before build commitment.
OpenStory
Workflow Discovery Story
The flagship story showing how discovery changed the product direction.
OpenArtifact
Discovery Memo
Representative memo for discovery synthesis and decision framing.
OpenArtifact
Opportunity Solution Tree
Representative opportunity map for discovery options.
OpenOperating System
Product Operating System
The broader principles and review habits behind this discovery decision.
OpenCapability Signal
What This Story Demonstrates
Primary Capability
Customer Discovery
Secondary Capability
SaaS Product Strategy
Product Principle
Users don't adopt products because they understand them. They adopt products because those products become part of the way they already work.
Discovery only becomes useful when it changes the product decision. In this case, the discovery work moved the team from adding more content to improving the workflow around how users found, evaluated, and used content in their real jobs.
Hiring Questions Answered
- How does Saurabh identify whether the team is solving the right product problem?
- How does he use customer discovery to challenge a plausible but incomplete roadmap assumption?
- How does he translate qualitative evidence into a product direction?
- How does he protect teams from building more output when the actual issue is workflow adoption?
Hiring Confidence
Why This Experience Matters
- Prepares me to challenge roadmap assumptions before teams commit expensive build capacity.
- Shows I can identify when an adoption problem is really a workflow-fit problem, not a supply or content-volume problem.
- Demonstrates comfort translating qualitative discovery into product strategy, opportunity framing, and prioritization.
- Shows I can align stakeholders around customer behavior even when the easier organizational answer is to build more.
- Prepares me to help AI, SaaS, and enterprise teams design products that fit into how users already work.
Capability Signal
Capabilities Demonstrated
Product DiscoveryCustomer ResearchProduct StrategyProduct PrioritizationStakeholder ManagementLeadership
Future Application
If I Joined Your Team Tomorrow
If I joined an AI, SaaS, or enterprise product team tomorrow, I would apply this lesson by asking where the product must fit into the user's real workflow before deciding what to build. Especially with AI products, adoption depends less on explaining capability and more on making the product useful inside existing habits, decisions, and constraints.
Interview Conversation