Leading Through Shared Goals [Roman Pichler]
The Product Leadership Conundrum
As the person in charge of a product, you are responsible for achieving product success. But you can’t accomplish it on your own and rely on the development team and stakeholders. Their contributions are vital to design, implement, provide, and support a successful product. At the same time, you can’t tell the individuals what to do or assign tasks to them, and you are typically not in a position to offer incentives, like a bonus or pay rise.
So how can you align people and ensure that everyone moves in the same direction and carries out the necessary work? And how do you ensure sufficient autonomy so that the individuals can own their work? Part of the solution is to establish a set of shared goals—goals that people support and that help you progress your product. The development team and stakeholders then use these goals to determine the work they have to do—be it creating a marketing strategy, investigating a new technology, or preparing the distribution channels. This focuses everyone on the joint outcomes you need to achieve, and it gives people the freedom to manage their work, thereby creating purpose and autonomy.
A Chain of Goals
Let’s take a look at the type of goals that help you move your product forward and align people.
The picture above shows a set of goals that are linked and operate at different levels. The first and possibly most powerful goal is the vision, which describes the ultimate reason for creating your product and the positive change it should bring about. An example I like to use is healthy eating. As this example shows, the vision is an inspirational, visionary goal that cannot be measured.
The user and business goals are strategic goals that are derived from the vision. The former describes the problem that users want to see addressed, for example, lose weight, or the benefit that users want to obtain, for instance, reduce the risk of developing diabetes. A business goal states the benefits the company developing and providing the product wants to achieve, for instance, diversify the business, open up a new revenue stream, and develop the main brand. Whatever user and business goals you choose, make sure that they are specific and measurable. This allows you too select the right key performance indictors (KPIs) and understand if your product is meeting its goals. I like to capture vision, user, and business goals on my Product Vision Board.
With user and business goals in place, you can take the next step and determine release goals. Each release goal should be a step towards meeting the user and business goals, and it should describe the specific benefits a major release or product version will provide, for example, acquire users, increase engagement, generate revenue, or remove technical debt to future-proof the product. I like to capture release goals on the product roadmap together with their metrics, and I have a preference to work with a goal-oriented (or themed) roadmap like my GO Product Roadmap.
Finally, identify the right sprint goal. A sprint goal states the desired outcome of a sprint, such as find out if users are willing to share personal information, test integration with leading smart scales, or finish the dashboard to release a first version to the test users. I recommend that you derive the sprint goal from the goal of the next major release and state it on the sprint backlog or task board. This ensures that each sprint moves you closer towards the release. (If your development team works with Kanban instead of Scrum, then it might still be helpful to agree on weekly goals that direct the work of the team members.)
Every sprint goal should be a step towards a release goal; every release goal should help you reach a user or business goal; and the user and business goals should help you realise your vision. The different goals are therefore linked and form a chain that covers all product planning aspects: visionary, strategic and tactical ones.
Getting to Shared Goals
It’s great to know what goals are helpful to direct and align the development team and stakeholders. But it’s not enough. The individuals involved in developing and providing the product must support the goals to move together in the same direction. Otherwise, people are likely to follow their own goals; orchestrating everyone’s efforts will become very difficult, if not impossible.
The best way to achieve strong-buy in is to actively involve the right people in the goal-setting process. I like to bring together the development team and key stakeholders and run a series of collaborative workshops: a strategizing workshop to come up with a meaningful, inspiring vision everybody believes in and a product strategy that contains user and business goals; a roadmapping workshop that identifies realistic release goals using the product strategy as an input; joint product strategy and roadmap review meetings to update or change to the strategy and roadmap; and sprint planning meetings that establish meaningful and realistic sprint goals. (Note that stakeholders don’t participate in sprint planning meetings. Instead, they are invited to sprint review meetings, which provide an opportunity to offer feedback on the latest product increment.)
Bringing together the right people allows you not only to generate strong buy-in; it also leverages their collective knowledge and creativity, and it establish meaningful goals—goals that are worthwhile to pursue. But a collaborative approach also carries the risk of friction and conflict. In the worst case, powerful individuals (HIPPOs) might highjack the goal-setting process and dictate goals.
To mitigate these risks, I recommend that you involve an experienced ScrumMaster, coach, or facilitator, who sets the ground rules, facilitates the workshops, ensures that everybody is heard, and nobody dominates. Additionally, make sure that you apply the right decision rule. As vision, user, and business goals are particularly crucial, you should attempt to achieve consensus with everybody fully supporting the goals. If that’s not possible, then discuss different options with the dev team and stakeholders, and then you decide as the person in charge of the product. (You may want to download my decision-making chart to select the right decision rule.)
If you feel that an open, collaborative approach is not feasible, then consider running individual meetings with the various stakeholders and development team to discuss a draft goal, incorporate people’s feedback, and rework the goal so that everybody can support it.
No matter which approach you choose, be careful that you don’t become a goal broker or mediator: Actively shape the goals and avoid making weak compromises to strike a deal or please people. Don’t be afraid to push back and say no when appropriate. At the same time, appreciate people’s ideas and concerns even if you feel they are not helpful or appropriate. When you care about the individuals, empathise with them, and understand their perspective and needs, they are more likely to support a goal even if they don’t fully agree with it.
Source: Roman Pichler https://www.romanpichler.com/blog/leading-through-shared-goals/
Post a Comment