Scoping Product Strategy:
Wants vs. Needs
April 23, 2026
Hi again! In my first post, I talked about the gap that led me to start Andromeda: teams with strong engineering and real momentum that hadn't yet invested in the product strategy layer. This post goes one level deeper: what happens when those teams actually reach out for help, and why the first conversation matters more than most people think.
The pattern: Asks vs. needs
The trend I've observed is that teams tend to reach out with an idea of what they think they need, and position it as a want. Someone says "I need a product strategy" or "I need market research" or "I need a roadmap." And those aren't wrong; they're reasonable starting points. But they're starting points, not conclusions.
On digging deeper, what usually happens is that the conversation sparks a thinking process that picks at the very roots of why someone might want, say, a roadmap or a specific type of analysis. And through that exploration, we end up narrowing down a different approach, a tweak to the original ask, or sometimes a completely different direction.
That's not a failure of the initial ask. That's a sign of collaborative growth and discussion. It means the scoping process is working.
How I figure out the real need
A key part of my initial information-gathering process with any new team or initiative is figuring out where they are in the product lifecycle. Are they pre-product, trying to figure out what to build? Are they post-MVP, trying to scale? Are they mid-growth, trying to figure out what's next? The answer to this question shapes everything downstream.
Fig. The product lifecycle framework I use to orient scoping conversations
Understanding their use cases, scenarios, and goals, both short and long term, based on their vision, is really the foundation for determining what they actually need.
From there, I like to work through a few things collaboratively, whether that's on a whiteboard or just a structured conversation:
Goals: What are they trying to accomplish in the next 2 months vs. the next 2 years?
OKRs: What concrete outcomes are they hoping to achieve? "I want to secure funding" is a direction, not an outcome. "Grow click-through rates by 15% month-over-month in the next quarter" is an outcome that rolls up to a larger objective like "grow adoption 2x in year one." That specificity matters.
Requirements: What does the work actually need to produce?
Scope: How much of this is realistic to tackle right now?
Timeline: and when does it need to happen?
This process does two things. First, it helps derive use cases that translate to real requirements: the actual needs, not the perceived ones. Second, it surfaces something I watch for carefully: the gap between excitement and realistic planning. When teams want to do everything at once, or can't differentiate passion from the drive to accomplish too many things within an unrealistic timeframe, that's a signal. It tells me there's an imbalance in their own understanding of strategy vs. execution. That's not a criticism. It's incredibly common, and it's exactly the kind of thing that should be caught during scoping, not three months into execution.
What happens when scoping goes wrong
If those foundational questions aren't discussed properly and early on, the foundation of setting the right expectations is missing. And that can make things go sideways fast.
What a team really needs is like the truth. They might not know about it or perceive it correctly at the time, but over time, those needs will surface over the asks. And when they do, there's often regret about the time and resources spent heading in the wrong direction.
This is something I saw repeatedly in corporate environments. Expensive mistakes like these happen frequently in larger organizations, and bigger companies tend to absorb the losses without fully reckoning with the root cause. Sometimes it's a lack of product sense from key decision-makers. Sometimes it's leaders applying mental models from past experience that worked in one context but don't transfer to the current situation. When leaders fail to adapt their knowledge and decision-making frameworks to ever-changing needs and markets, that's when the wrong asks surface and end up blurring the real needs.
There's another pattern I've noticed that compounds this: the dismissal of the actual user's needs and experiences. Teams sometimes operate on assumptions about their target users - assumptions based on outdated research data, or worse, no research data at all. When building products, it's important to understand how user needs evolve over time with changing factors like market dynamics, competitive landscapes, emerging demographics, and shifting economic conditions. A strategy built on stale user assumptions is a strategy built on sand. This isn't just a big-company problem. The same mistake happens even with early-stage teams with smaller budgets and tighter margins for error.
What well-scoped actually looks like
In my experience, a good scope should give the client confidence that a realistic set of outcomes is achievable within the timeframe proposed. Not everything they want, but what's actually achievable. And it should account for:
Assumptions about factors relevant to their market, sector, or industry that could shift
Internal assumptions about the company's own situation: budget, hiring, capacity etc.
Foreseeable risks and roadblocks that could slow things down or change the plan
A reasonable buffer that accounts for all of the above because things always take longer than expected
A couple of stretch goals, things that are nice to have but won't derail the engagement if they don't happen
The stretch goals matter more than people think. They give the engagement room to overdeliver without promising the moon. And they give the client a clear picture of what "exceeding expectations" looks like versus what "meeting expectations" looks like. That distinction sets the right tone for the whole relationship.
The bigger point
Helping teams understand how to build a phased approach around their strategy, while incorporating dependencies and potential risks, is part of navigating ambiguity. That's a core founding principle for Andromeda.
The scoping conversation isn't a formality. It's the first act of the strategic work itself. If someone walks away from an intro call with a clearer picture of what they actually need (even if it's different from what they came in asking for), then the process is already delivering value before any contract is signed or any execution commences.
Next up: Probing questions I ask before touching a roadmap.
Thanks for reading!
Interested in discussing further? Feel free to get in touch: annie@andromedatech.io
