The 10x Product Development Shift: From Project to Product Thinking
One of the most common afflictions of modern product organizations is the disease of delivery focus. By making the shift from project to product thinking, you can 10x your product development:
Delivery focus is a result of project thinking. Even in Silicon Valley, this creeps into companies as they grow. Often as companies grow, their product innovation slows. Sales, marketing, or another business function becomes the engine for growth.
This results in that engine of growth gaining increasing say over what is built. And what is the natural working relationship? The team develops feature ideas — “solutions”. They then come to tech to build them. This exerts gravitational force to delivery & project thinking.
And kneecaps the effectiveness of the tech org. Product managers become project managers, if they exist at all. Instead of focusing on:
- What & why
- Outcomes
- Effectiveness
- Creativity
The tech org focuses on:
- How & when
- Outputs
- Efficiency
- Discipline
The company’s developers are turned into a “feature factory”. Thus the disease of delivery focus is: When tech orgs get into a project delivery mindset at the expense of empowered product thinking. It’s been alternatively called the “build trap”.
What to do if your company is going through this disease? There are 3 solutions:
- Embed the growth engines
- Problems not solutions
- Outcomes not outputs
1. Embed the growth engines
Don’t operate in two silos: “feature generators” and “feature developers”. Bring the teams together. If sales is the driver, embed sales people into the product teams. Have them participate in the feature discovery process on empowered teams.
2. Problems not solutions
These autonomous product teams should not sign up for solutions or features in planning. They should focus on solving specific problems. This allows the empowered teams to leverage the full powers of the designers, engineers, and PMs.
3. Outcomes not outputs
Finally, the teams should be measured on outcomes, not outputs. They need to be able to step off the product treadmill of feature releases. Their yardstick becomes specific metrics, not specific features.
These steps, when put together, represent a “releasing” of control. Executives & stakeholders don’t come to the tech org with features. They trust empowered teams to solve problems & achieve outcomes.
If you enjoyed this, you’ll love the product growth newsletter.
