After 750+ architecture reviews at Microsoft, I discovered the difference between products that ship and projects that drift. It’s not about perfect requirements or brilliant ideas. It’s about shaping.
The Problem: Building Without Shaping
Most product managers jump straight from idea to backlog. They gather requirements, write user stories, and start sprinting.
Six months later, they’re lost in feature factory hell, building something nobody quite remembers asking for.
The best PMs do something different first. They shape the work before they build it.
The SHIP Framework
S – Scope the Problem
H – Hammer the Solution
I – Identify the Risks
P – Package the Pitch
This is the framework I used to ship products at Microsoft, and it’s what separates products that launch from projects that languish.
S – Scope the Problem (Not the Solution)
Most PMs start here: “We need a dashboard.”
Start here instead: “Teams can’t see progress toward goals.”
The difference? The first locks you into a solution. The second opens up possibilities.
The Scoping Canvas:
- Problem: What’s broken? (Be specific)
- Evidence: How do you know? (Data, quotes, metrics)
- Impact: What happens if we don’t fix it? (Cost of inaction)
- Success: What does “fixed” look like? (Observable outcome)
Real Example from Microsoft:
- ? “We need better search”
- ? “Engineers waste 2.5 hours/week finding code examples, costing $31M annually in productivity”
The second version shapes action. It has urgency. It has measurement. It ships.
H – Hammer the Solution (Into Shape)
Once you’ve scoped the problem, you hammer out a solution – but not in detail. You’re shaping clay, not engineering blueprints.
The Shaping Questions:
- What’s the core workflow? (5-7 steps max)
- What’s the “bread and butter” path? (The 80% use case)
- What are we NOT building? (Equally important)
- How long should this take? (Time appetite, not estimate)
The 6-Week Rule: If it takes longer than 6 weeks to ship something meaningful, you haven’t shaped it enough. Break it down further.
Shaping in Practice:
Instead of: “Build a complete analytics dashboard with 15 widgets, custom reports, real-time updates, and Excel export”
Shape it to: “Show three numbers that matter: current sprint velocity, release countdown, and blocker count. Read-only. Updates daily. Ships in 3 weeks.”
The shaped version ships. The unshaped version becomes a year-long death march.
I – Identify the Risks (Before They Identify You)
Every product has landmines. The best PMs find them during shaping, not during sprint 5.
The Risk Radar – Check Four Dimensions:
- Technical Risk: What could break our architecture?
- Integration points
- Performance bottlenecks
- Security concerns
- Design Risk: What could confuse users?
- New mental models
- Mobile responsiveness
- Accessibility requirements
- Dependency Risk: What could block us?
- Other teams’ roadmaps
- API availability
- Legal/compliance reviews
- Adoption Risk: What could prevent usage?
- Change management needs
- Training requirements
- Migration complexity
For each risk, document:
- Probability (High/Medium/Low)
- Impact (High/Medium/Low)
- Mitigation (What we’ll do about it)
Pro tip: If you have more than 3 high/high risks, you haven’t shaped enough. Go back to H.
P – Package the Pitch (So It Actually Gets Built)
Great shaping means nothing if you can’t sell it. The pitch is how you turn shaped work into shipped work.
The One-Page Pitch Template:
Problem (One sentence) “Engineers waste 2.5 hours/week finding code examples.”
Solution (One paragraph) “A searchable library of our top 100 most-reused code patterns, accessible via IDE plugin. Engineers type ‘pattern:auth’ and get instant, approved examples. No new tools to learn.”
Appetite (Time investment) “4 weeks with 2 engineers and 1 designer”
Impact (Measurable outcome) “Save 30 minutes/week per engineer = $6M annual productivity gain”
Risks (Honest assessment) “Main risk: IDE plugin compatibility across versions. Mitigation: Start with VS Code only (85% of team), add others later.”
Not Doing (Explicit boundaries) “Not building: Custom code generator, AI suggestions, or multi-language support. Those can come later if this works.”
This pitch took 5 minutes to read and got approved same day. Why? Because it was shaped.
The Shaping Rhythm
Week 1-2: Shape
- Scope problems from customer feedback
- Hammer 2-3 solution approaches
- Identify risks for each
- Pick the best approach
Week 3-4: Pitch
- Package the pitch
- Get feedback from engineering/design
- Refine based on input
- Get approval to proceed
Week 5-10: Build
- Hand shaped work to delivery team
- No feature creep (it’s already shaped!)
- Ship on time
Week 11-12: Learn
- Measure actual vs. expected impact
- Gather feedback
- Shape the next iteration
Why Shaping Works
Without Shaping:
- Requirements ? Design ? Build ? Discover problems ? Redesign ? Rebuild ? Maybe ship
With Shaping:
- Shape ? Pitch ? Build ? Ship ? Learn ? Shape better
The difference? Shaping front-loads the thinking.
You solve problems on paper (cheap) instead of in code (expensive).
Your Next Steps
- Pick one problem your team faces right now
- Run it through SHIP (Should take 2 hours)
- Write a one-page pitch (30 minutes)
- Share it with your team (Watch what happens)
The first time you ship something in 6 weeks that usually takes 6 months, you’ll never go back to the old way.
The Bottom Line
Products don’t ship because they’re perfectly planned.
They ship because they’re properly shaped.
Stop building everything. Start shaping what matters.
Then ship it.
J.D. Meier shaped products for 20+ years at Microsoft. He performed 750+ architecture reviews and authored 10 books on building software that ships.