Annelore Arnold, Agile coach, Scrum Master and Digital Product Owner at a big Telecom player, is passionate about building products that customers and teams love. It’s every Product Owner’s dream to have a product or service that the customers will love and have a highly motivated and passionate team to build the product. In this article Annelore shares her experience and vision on how to exactly do that. She explains how to develop products with Purpose, with capital P!
Output vs Purpose
In general, most product development teams have a high focus on output. They build a particular solution, or a set of features, based on a set of given requirements. It’s the Product Owner’s job to clearly define the features.
In this classic setup, the development is mostly scope-driven and plan-driven.
And its success is measured by output, for example by the number of features delivered by a specific deadline. As a consequence, velocity is often the main driver for most Agile teams.
What if you looked at things a bit differently and started focusing on Purpose rather than on output? Although the output-driven approach seems a very acceptable and logical way of working, it has a very fundamental flaw. This approach is namely based on the assumption that we can predict and plan which product is needed and when, and that we can know the customer’s needs in advance.
Reality however has taught us that in complex product development, customers actually only know what they want, when they see and use the product. They often discover what they need and want along the way. The basic needs of a consumer application often differ significantly from what was initially expected. That is where the Jobs-to-be-done concept comes into play.
On top of that, organizations are not using the full potential of the creative capabilities and collective intelligence available in order to create better and alternative solutions. Intent-based leadership can offer a solution to this.
Both the jobs-to-be-done concept and the Intent-based leadership will be explained more into detail in the next sections. But first things first:
Why focus on Purpose rather than on output?
Annelore has experienced a different, Purpose-driven approach as Product Owner of a mobile application team at a big Telecom player. When the main driver of product development becomes purpose, setting the purpose as a vision allows everyone to focus on the outcome.
Based on that purpose, the objectives or goals can be set. If needed, those objectives can be further refined in smaller anchor points on the shorter term.
Purpose can be that powerful tool to empower and motivate your teams, allowing them to focus on what matters, and to create real value. It helps all stakeholders to keep the right focus on what you want to achieve in the long term.
Daniel Pink, author of “Drive”, already talked about purpose in his book. According to him, there are 3 main ingredients for the recipe for an environment that helps people flourish. People are intrinsically motivated by:
- A clear purpose
- Autonomy
- Mastery
So as a product owner, make sure to focus on setting a clear purpose and clear goals. Challenge and engage your teams in creative thinking and allow them to co-create solutions, allowing them the much desired autonomy.
Spotify for example, already started a long time ago with creating environments where teams have a high degree of autonomy and alignment.
By giving the development teams direction, direct contact or a clear view on the stakeholders and the customers, these teams can come up with solutions that better suit the customers needs. It is of course crucial to add regular user research and testing and to make sure to mix product discovery with product development in order to achieve the purpose.
As mentioned before, the 2 other important concepts to take into consideration in your product development model are ‘job-to-be-done’ and ‘intent-based leadership’.
What is the Job-to-be-done (JTBD) framework?
It is an approach first defined by Clayton Christensen who was an American economist and academic, to understand customers and their motivation to buy a product or service. His theory states that customers mainly buy something because they experience a problem that they would like to solve. The main question is what job do consumers want done by buying a certain product or service? When we buy a product or service, we ‘hire’ something to get a ‘job’ done or a problem solved.
The origin of the JTBD theory is linked to milkshakes. McDonalds wanted to increase their milkshake sales. They interviewed customers asking them what flavors they wanted, whether they wanted bigger or smaller,… Turned out that after they implemented the customer’s feedback, there still was no increase in milkshake sales.
Clayton Christensen was brought in and he used his JTBD theory to find out exactly why customers bought a milkshake. What was the job to be done by the milkshake? Turned out customers needed something they could easily take along their commute drive and drink up when they got hungry along the way. McDonalds was not competing against its competitors, it was competing against other snacks. So once they learned the job to be done, they could make the necessary changes (e.g. making them more accessible on the front counter) to make it easier on the customer to get the job done, with a milkshake!
So instead of thinking about what solution/product/service to build, based upon the assumption that customers know and say what they need or want, do research and experiments to figure out what job the product will do.
JTBD and mobile apps
If we apply the JTBD approach to mobile apps, the first question to ask ourselves is: what is the first function an app needs to fulfill?
Apps mainly satisfy people’s need to kill time, to be entertained, not to be bored, … There is a reason why we all check the news or refresh our social media feed several times a day!
The primary job to be done by a Telecom app? Help people check their bills, consult the details of their mobile or internet subscription packages or contact the customer support team.
This ‘job to be done’ or purpose allows for the planning of incremental releases rather than assuming all features need to be developed before the first release.
Intent-based leadership
David Marquet, bestselling author of Turn the Ship Around and Leadership is Language, is the creator of Intent-Based Leadership. He based his theory on his experience as a United States Navy captain, changing the leadership on the nuclear submarine under his command from ‘leading by giving instructions’ to ‘leading from intent’. Completely changing the way the ship was run. He became the expert on leadership that allows people to be happier because they have more autonomy and control over their work.
Intent-based leadership is very similar to purpose-driven leadership.
In a non intent-based leadership environment, people often have to request permission for their actions. An intent-based leadership style allows team members to express their intent to do something. As a leader, instead of telling your team members what to do, you give your team members the opportunity to figure it out by themselves. This allows for more autonomy, more creativity and thus better results.
Making purpose work
What are the obstacles Product Owners need to tackle in order to make sure their organization adopts the purpose-driven product development model?
A common anti-pattern is that product stakeholders often create a list of requirements for the team to implement. The Product Owner acts as a go-between and has only a limited (or sometimes even no) degree of autonomy over the order of items.
Product Owners are basically not given the necessary authority to make decisions for the product, resulting in longer than needed decision-making cycles or overruling of decisions made. Product Developers are not given the trust or opportunity to generate creative ideas to solve problems and organizations stimulate stakeholders to develop and request solutions, instead of identifying problems and framing user and business needs.
Make the purpose-driven model work by trying to change these working patterns and obviously avoiding these above mentioned anti-patterns.
Start by setting a clear purpose, define impact, create a roadmap for features in the coming quarter at the most and always keep options open!
And that is what real (Agile) Product Ownership is about.
We want to thank Annelore for her insights and her inspiring vision.
Do you want to know more about Annelore Arnold? Check out Annelore’s LinkedIn profile.
