PROCESS DESIGN | PRODUCT OPERATIONS
How do you add structure without adding bureaucracy?
Product teams needed a more consistent way to evaluate ideas and requests before they became committed work. But adding another heavy intake process would have created a different problem.
I designed an upstream discovery process that gave teams enough structure to frame the problem, surface assumptions, gather the evidence needed, and decide what deserved further investment before work entered the delivery pipeline.
The Process Challenge
Ideas and requests entered the portfolio from different directions and at different levels of maturity. Some started with a clearly understood problem. Others arrived with a solution already attached. Teams had established processes for managing work once it reached delivery, but there wasn't a consistent way to determine what should happen before that point.
The challenge wasn't simply creating an intake form. It was designing a way for teams to slow down just enough to ask the right questions without creating a bottleneck between an idea and the people responsible for moving it forward.
The process needed to create better thinking, not more paperwork.
The issue wasn't a lack of ideas. It was that ideas entered the portfolio with very different levels of understanding behind them.
Some requests arrived with a solution already attached. Others represented legitimate needs but lacked enough evidence to understand their impact. And because opportunities could touch multiple products, it wasn't always obvious who should investigate them or what needed to happen next.
What was missing was a consistent way to turn an incoming request into something teams could actually evaluate.
Before teams could prioritize the work, they needed a better way to understand it.
What I Saw
What I Changed
I designed a lightweight upstream intake and discovery process to create consistency without forcing every opportunity through the same path. The process helped teams understand the problem, identify what they needed to learn, and determine the right next step before work moved toward delivery.
The goal was enough structure to improve the decision, without turning discovery into another gate.
01
Separate the Problem From the Request
Get past the feature or proposed solution and establish the underlying problem, who experiences it, and what outcome is needed.
02
Surface What We Don't Know
Identify assumptions, existing evidence, unanswered questions, and what needs to be learned before the opportunity can be evaluated.
03
Match Discovery to the Decision
Determine what research or validation is actually necessary to reduce uncertainty and make the next decision, rather than forcing every opportunity through the same activities.
How the Process Worked
The process created a shared starting point, then scaled the depth of discovery based on what teams already knew, what remained uncertain, and what decision needed to be made.
01
02
03
04
05
REQUEST ENTERS
Capture the need, context, and desired outcome.
FRAME THE PROBLEM
Separate the underlying problem from the proposed solution.
IDENTIFY THE GAPS
Surface assumptions, existing evidence, and unanswered questions.
DISCOVER & VALIDATE
Use the research needed to reduce the most important uncertainty.
MAKE DECISION
Use what was learned to determine the appropriate next step.
Not every opportunity followed the same path or required the same amount of discovery.
The process created consistency in the questions teams asked, not rigidity in how they answered them.
What Changed Because of It
The intake process created a more consistent way to move from “someone has an idea” to “we understand enough to prioritize what should happen next.” Teams could spend less time sorting out requests and more time investigating the opportunities that actually warranted attention.
01 | Stronger Starting Points
02 | Discovery With a Purpose
Teams had more to work with than a request.
Opportunities entered the conversation with clearer problem statements, context, desired outcomes, known evidence, and unanswered questions, giving teams a stronger foundation for deciding what needed to happen next.
Research was tied to a decision, not a checklist.
Teams could identify what was actually uncertain and choose the level of research or validation needed to reduce that uncertainty rather than automatically putting every request through the same discovery activities.
03 | Clearer Ownership
04 | Better Decisions Before Delivery
Cross-product opportunities had somewhere to go.
By understanding the problem before assigning the work, teams could better determine which product or group should investigate an opportunity, including requests that crossed traditional product boundaries.
Teams could decide whether an opportunity deserved investment.
The process created space to test assumptions and strengthen the evidence behind an opportunity before it became a roadmap commitment, requirement, or delivery expectation.
What This Taught Me
A good intake process doesn't just organize requests. It improves the decisions made about them.
This work reinforced that intake is more than a place for requests to land. The way an opportunity enters an organization can shape everything that happens afterward. If a solution is treated as a requirement before the problem is understood, teams can spend significant time investigating how to deliver something before asking whether it is the right thing to do.
The most useful process wasn't the one with the most steps. It was the one that helped people ask the right questions at the right time, surface what they didn't know, and create enough shared understanding to make a better decision about what should happen next.