www.svpg.com/transformation-defined/
5 Users
0 Comments
26 Highlights
2 Notes
Authors
Top Highlights
If you’re not doing continuous delivery, then at the very least you should be doing true releases no less than every two weeks.
A strong product-led company has a compelling product vision, and an insight-based product strategy to identify the most critical problems to solve in order to deliver on the business objectives.
This is the core of what is meant by moving from Feature Teams to Empowered Product Teams. Instead of stakeholders prioritizing their perceived solutions (features and projects) and providing these in the form of a roadmap to a feature team, now the product team is assigned problems to solve, and the product team is empowered to discover a solution that is valuable, usable, feasible and viable. In practice this means developing the skills to do product discovery, and ensuring that your engineers and product designers have a true product manager (skilled in the customers, the data, the business and the industry) so that the product team has the necessary cross-functional skills to succeed. It’s important to note that this change implies a new relationship with the company stakeholders; where the product team moves from a subservient relationship, to a collaborative relationship where the product team must discover a solution that the customers love yet works for the business.
strong product-led company has a compelling product vision, and an insight-based product strategy to identify the most critical problems to solve in order to deliver on the business objectives.
all three of these changes depend on strong product leaders
In practice this means developing the skills to do product discovery, and ensuring that your engineers and product designers have a true product manager (skilled in the customers, the data, the business and the industry) so that the product team has the necessary cross-functional skills to succeed.
First, all three of these changes depend on strong product leaders
Changing how you build and deploy means moving from big quarterly releases to a cadence of small, consistent releases. Changing how you solve problems means moving from stakeholder-driven roadmaps and feature teams, to empowered product teams given problems to solve, and then using product discovery to come up with solutions that are valuable, usable, feasible and viable. Changing how you decide which problems to solve is typically the most profound change of all, as this drives what opportunities you choose to pursue, and how you make the most out of the investment you make, including product vision and product strategy.
Changing how you build and deploy means moving from big quarterly releases to a cadence of small, consistent releases. Changing how you solve problems means moving from stakeholder-driven roadmaps and feature teams, to empowered product teams given problems to solve, and then using product discovery to come up with solutions that are valuable, usable, feasible and viable. Changing how you decide which problems to solve is typically the most profound change of all, as this drives what opportunities you choose to pursue, and how you make the most out of the investment you make, including product vision and product strategy.
Every company faces many threats and many opportunities. Which threats you take seriously, and which opportunities you decide to pursue, can mean the difference between success and failure.
One question that we get quite frequently is, “what can a company that has transformed do better than a company that hasn’t?”
Changing How You Build and Deploy
If you’re not doing continuous delivery, then at the very least you should be doing true releases no less than every two weeks
Instead of stakeholders prioritizing their perceived solutions (features and projects) and providing these in the form of a roadmap to a feature team, now the product team is assigned problems to solve, and the product team is empowered to discover a solution that is valuable, usable, feasible and viable.
In practice this means developing the skills to do product discovery, and ensuring that your engineers and product designers have a true product manager (skilled in the customers, the data, the business and the industry) so that the product team has the necessary cross-functional skills to succeed.
It’s important to note that this change implies a new relationship with the company stakeholders; where the product team moves from a subservient relationship, to a collaborative relationship where the product team must discover a solution that the customers love yet works for the business.
Changing how you build and deploy means moving from big quarterly releases to a cadence of small, consistent releases. Changing how you solve problems means moving from stakeholder-driven roadmaps and feature teams, to empowered product teams given problems to solve, and then using product discovery to come up with solutions that are valuable, usable, feasible and viable. Changing how you decide which problems to solve is typically the most profound change of all, as this drives what opportunities you choose to pursue, and how you make the most out of the investment you make, including product vision and product strategy. Hopefully this framing can help you think more holistically about the transformation that your company may need, and where you may be on that journey.
Despite Agile being around for so many years, there are still far too many companies stuck doing quarterly (or worse), big-bang releases.
Changing how you solve problems means moving from stakeholder-driven roadmaps and feature teams, to empowered product teams
s given problems to solve
Glasp is a social web highlighter that people can highlight and organize quotes and thoughts from the web, and access other like-minded people’s learning.