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. By looking across product boundaries, I helped connect insights, challenge assumptions, and create more consistent ways to evaluate opportunities before teams committed delivery resources.
The Portfolio Challenge
The portfolio included multiple enterprise products designed to help teams organize, understand, and maintain reliable data. Each product had its own roadmap and priorities, but they weren't operating independently. They shared users, workflows, data, technical foundations, and resources, which meant decisions made within one product could create ripple effects across others.
Teams were understandably focused on the needs directly in front of them. The opportunity was to zoom out and understand how those decisions connected across the portfolio, while bringing user evidence into the conversation early enough to influence what problems teams chose to solve.
Looking across the portfolio revealed a pattern: teams had established ways to manage and deliver work once it entered the roadmap, but the thinking that happened before that point wasn't always as consistent.
Requests could arrive with a solution already attached. Assumptions about user needs weren't always validated early enough. Research conducted for one product could hold useful insight for another, but there wasn't a consistent way to connect that knowledge across the portfolio.
The opportunity was upstream, before a request became a requirement, a feature, or a commitment of delivery resources.
Better decisions downstream started with better questions upstream.
What I Saw
What I Changed
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.
The goal was to help teams ask better questions sooner, test the assumptions behind requests, and determine whether an opportunity was worth pursuing before it became committed work.
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 teams moved toward delivery.
Problem Framing · Hypothesis Development · Discovery
02
Bring Evidence Into the Decision
I introduced research earlier in the process to test assumptions about what users actually needed, using qualitative and quantitative evidence to strengthen decisions before resources were committed.
User research · UserZoom · Analytics
03
Connect Insight Across Products
I helped create a shared research foundation so insights from one product could inform questions and decisions elsewhere in the portfolio rather than remaining isolated within individual teams.
Dovetail · Research Synthesis · Portfolio Insight
A Shared Decision Lens
To create more consistency in how opportunities were evaluated, I used three questions to bring different perspectives into the decision before teams committed to delivery:
DESIRABILITY
Do people actually need this?
Use research and evidence to understand the problem, who experiences it, and whether solving it would create meaningful value.
VIABILITY
Does it make sense for the business?
Consider organizational priorities, expected value, constraints, and whether the opportunity is worth the investment.
FEASIBILITY
Can we realistically do it?
Bring technical partners into the conversation early enough to understand complexity, dependencies, constraints, and what is realistically possible.
The point wasn't to check three boxes. It was to make sure one perspective wasn't making the decision for everyone else.
What Changed Because of It
The value wasn't another framework or process. It was giving teams a more consistent way to think through opportunities before they became committed work.
01 | Better Problem Framing
02 | Evidence Earlier in the Conversation
Teams had a stronger starting point.
Requests could be separated from the solutions attached to them, giving teams clearer problem statements and stronger hypotheses to investigate before deciding what to build.
User insight shaped what moved forward.
Research became part of evaluating opportunities upstream, helping teams test assumptions and strengthen business cases before committing delivery resources.
03 | Insight Beyond a Single Product
04 | More Confidence in What Moved Forward
Research became more useful across the portfolio.
A shared research foundation made it easier to connect findings across products, identify recurring needs, and bring existing evidence into new conversations instead of starting from scratch.
Teams had more than one perspective informing the decision.
Bringing customer desirability, business viability, and technical feasibility together helped teams make more informed decisions about which opportunities warranted further investment.
What This Taught Me
Good product decisions start before something becomes a product decision.
This work reinforced that many of the decisions that shape a product happen long before something reaches a roadmap. How a request is framed, which assumptions are treated as facts, whose perspective is included, and what evidence is available can all influence what a team ultimately decides to build.
Working across the portfolio also changed how I think about design strategy. Sometimes the greatest value isn't designing the solution. It's creating better ways for people to decide which problems deserve solving in the first place.