Enterprise design strategy · Technology portfolio
What changes when you stop looking at products one at a time?
I was embedded as a design strategist across a portfolio of interconnected enterprise technology products, working upstream of delivery to bring user needs and evidence into decisions about what teams should solve and why.
The products were designed to help teams organize, understand, and maintain reliable data. Each had its own roadmap, but they weren’t operating independently. They shared users, workflows, data, technical foundations, and resources, so a decision made within one product could ripple across the others. Ideas and requests also arrived 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 ways to manage work once it reached delivery, but no consistent way to decide what should happen before that point, and research done for one product could hold useful insight for another with no reliable way to connect the two.
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.
What I changed
Better decisions downstream started with better questions upstream.
I focused on strengthening the space between an idea entering the portfolio and a team deciding what to do with it. Rather than introducing another layer of process, I worked with product teams to make problem framing, user evidence, and cross-product insight a more consistent part of early decision-making.
01 · Frame the problem
Before the solution.
I helped teams separate the underlying need from the solution attached to a request, creating stronger problem statements and hypotheses before work moved toward delivery.
Problem framing · Hypotheses · Discovery
02 · Bring evidence in
Into the decision.
I introduced research earlier to test assumptions about what users actually needed, using qualitative and quantitative evidence before resources were committed.
User research · UserZoom · Analytics
03 · Connect insight
Across products.
I helped create a shared research foundation so insight from one product could inform questions and decisions elsewhere in the portfolio instead of staying isolated within individual teams.
Dovetail · Research synthesis
How it worked
A shared starting point, scaled to the decision.
The intake process gave every request the same starting point, then scaled the depth of discovery to what teams already knew, what remained uncertain, and what decision needed to be made.
To bring different perspectives into the decision, I paired it with a shared lens of three questions:
Desirability
Do people actually need this?
Use research and evidence to understand the problem, who experiences it, and whether solving it creates meaningful value.
Viability
Does it make sense for the business?
Consider priorities, expected value, constraints, and whether it’s worth the investment.
Feasibility
Can we realistically do it?
Bring technical partners in early enough to understand complexity, dependencies, and what’s possible.
What changed because of it
A more consistent way to think through opportunities before they became committed work.
Teams spent less time sorting out requests and more time investigating the opportunities that actually warranted attention.
01 · Stronger starting points
Teams had more to work with than a request.
Opportunities arrived with clearer problem statements, context, desired outcomes, known evidence, and open questions.
02 · Discovery with a purpose
Research was tied to a decision, not a checklist.
Teams chose the level of validation needed to reduce real uncertainty instead of putting every request through the same activities.
03 · Insight beyond one product
Research became more useful across the portfolio.
A shared foundation made it easier to spot recurring needs, route cross-product requests to the right group, and bring existing evidence into new conversations.
04 · More confidence
More than one perspective informed the decision.
Desirability, viability, and feasibility came together before an opportunity became a roadmap commitment, requirement, or delivery expectation.
What this taught me
Good product decisions start before something becomes a product decision.
Many of the decisions that shape a product happen long before it reaches a roadmap. How a request is framed, which assumptions are treated as facts, whose perspective is included, and what evidence is available all influence what a team decides to build. 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’s the right thing to do.
Too many requests, too little clarity?
Let’s help your teams decide what’s worth building.
Structure that sharpens decisions, without adding bureaucracy.
Let’s talk →or email sbinger@stephaniebinger.com
Better questions lead to brighter ideas.