Tag Archives: product manager

Getting lost in the product details and struggling to decide if a feature should be implemented is a common challenge for product owners and product managers. It’s something that happens to me all the time, even while I was writing this post. But as product owners, we should focus on what really counts: creating value for the people using the product and the organisation developing it.

What’s in it for the User?

Some product owners I work with worry too much about how to write a certain user story or what the detailed design of a screen should look like. Whenever this happens, I find it helpful to step back and ask the following questions: Why would anybody want to use the functionality? Why would a certain design be helpful?

I know the image above looks pretty trivial. But it took me a few iterations to create it. I started out with a more elaborate design, which I dropped after I reflected on the desired user benefit: Glancing at the images should allow the reader to understand the gist of the blog post. Selecting a simpler design hopefully achieves this goal better.

The Product is a Means to an End

Exploring how a story or design idea benefits the users means viewing the product as a means to an end: to serve the users as well as the organisation creating it. As marketing guru Theodore Levitt famously put it, “People don’t want a quarter-inch drill, they want a quarter-inch hole.” What really matters are the benefits the product provides.

I find that personas and scenarios are great to hypothesize about the users and their needs. A persona allows us to capture assumptions and ideas about what a typical user might be. The scenarios describe the user’s problem, how our product should benefit the user together with the desired user experience.

While serving the user should be the primary purpose of your product, you shouldn’t forget about the value the product has to create for your organisation. To do so, reflect on the business model that will help you achieve your business goals. This includes identifying the revenue streams, the sales channels, and the cost structure. A great tool to analyse and improve your business model is the Business Model Canvas created by Alexander Osterwalder and Yves Pigneur.

Be aware that your business model can have an impact on the product functionality: For instance, if you plan to generate revenue through online ads, then this requires the capability to place ads. As a consequence, an ad epic will appear in your product backlog.

To capture your ideas about user needs, the product, and the value created for the company, you may want to try my Vision Board. The board captures assumptions about the target group, the user needs, the top three features, and the key business model elements.

Users Come First!

If you find it difficult to balance meeting the user needs and creating value for your organisation, then focus on the user. If your product is desirable, you are likely to find a way to make money. Users should come first, money second.


Next time when you get stuck in the product details, zoom out. Ask yourself how a feature adds value for the users and your organisation. Then implement it, gather the relevant data, and check if the benefit has been realised. Happy developing!

Applying the product owner role can be challenging, as no two products are the same. While products and projects vary, I have found two common ways to employ the role: Asking the customer or a customer proxy such as a product manager to take on the product owner role. This post discusses when the two alternatives are appropriate together with their advantages and challenges.

The Customer Plays the Product Owner Role

One way to apply the product owner role is to ask the customer to play the role. This option is particularly useful for the development of bespoke (custom) software. For instance, if a web application is developed for a company’s marketing group – either by an in-house team or by an external software provider – a member of the marketing group should take on the product owner role. This approach is illustrated by figure 1:

Figure 1

Advantages: The customer steers and controls the development of the software directly. This allows the customer to own the product, speeds up decision-making, and increases the likelihood of creating a product that serves the customer needs.

Challenges: The customer must be available, qualified, and empowered to create a successful product. The customer and the team must value transparency and develop a healthy, trustful relationship. The latter tends to be particularly challenging when the customer and the team have different interests, for instance, getting the essential features shipped as soon as possible vs. maximising revenue, or if they have had difficulties to collaborate in the past (“IT never delivers”).

A Customer Proxy Fills the Product Owner Role

Alternatively, we can decide to separate the customer and the product owner role. This option is applicable when software is developed for several customers, for instance, when a commercial software product is created or when different departments of the same company use software developed in-house. In both scenarios, the product owner acts as a customer proxy who listens to the ideas and requirements of the customers and users but decides when which features are released. Figure 2 summarises this option:

Figure 2

For commercial software, a product managers typically takes on the product owner role. For software developed in-house, a project manager or business analyst may play the role. Note that figure 2 illustrates the main communication paths. Team members talk to customers and users directly of course, for instance, in the sprint review meeting when discussing improvements to the product. (But ultimately the product owner decides which improvements are implemented.)

Advantages: Separating the customer and the product owner role helps create a product that addresses all the needs selected. It also provides the opportunity to employ professional full-time product owners with the right skills: Product managers, project managers, and business analysts can focus on playing the role effectively.

Challenges: Empowerment of the product owner can be difficult to achieve: Product owners often require the trust and support of senior management to be able to make the necessary decisions, to have the clout to say no, and to create stakeholder alignment. Companies that regard IT largely as a commodity can find it difficult to value product ownership and to invest in developing product owners.

Mix and Match

I recommend that you apply one of the patterns described above to each of your products. To put it differently, a product should either be managed by a customer or by a customer proxy. But there is no reason why you cannot mix and match the two patterns across your portfolio: Choose customer product owners for bespoke products and customer proxies for products that serve several customers.


1 Start with the Users

As its name suggests, a user story describes how a customer or a user employs the product. You should therefore tell the stories from the user’s perspective. What’s more, user stories are particularly helpful to capture a specific piece of functionality such as searching for a product or making a booking, as the following picture illustrates.  UserStoryOverview

2 Use Personas to Discover the Right Stories

A great way to capture your insights about the users and customers is to use personas. But there is more to it: The persona goals help you discover your stories. Simply ask yourself: What functionality does the product have to provide to meet the goal of the personas? You can download a handy persona template for free from romanpichler.com/tools/persona-template and you can learn more about this technique in my post From Personas to User Stories.


3 Write Stories Collaboratively

A user story is not a specification, but an communication and collaboration tool. Stories should never be handed off to the development team. They should rather be part of a conversation: The product owner and the team should discuss the stories, or even better, write them together. This leverages the creativity and the knowledge of the team and usually results in better user stories.


4 Keep your Stories Simple and Concise

Write your stories so that they are easy to understand. Keep them simple and concise. Avoid confusing and ambiguous terms, and use active voice. Focus on what’s important, and leave out non-essential information. The following template puts the user or customer modelled as a persona into the story and makes its benefit explicit. Use the template when it is helpful, but don’t feel obliged to apply it. Experiment with different ways to write your stories to understand what works best for you and your team. StoryTemplate

5 Start with Epics

Epics are big, coarse-grained user stories. Starting with epics allows you to sketch the product functionality without committing to the details. This is particularly helpful for new products and new features: It allows you to capture the rough scope, and it buys you time to learn more about the users and how to best meet their needs. It also reduces the time and effort required to integrate new insights. If you have lots of detailed stories, then it’s often tricky and time-consuming to relate any feedback to the right stories.

6 Decompose your Stories until they are Ready

Break your epics into smaller, detailed stories until they are ready: clear, feasible, and testable. Everyone should have a shared understanding of the story’s meaning; the story should not too big, and there has to be an effective way to determine if the story is done. EpicVsReadyStory

7 Add Acceptance Criteria

As you decompose epics into smaller stories, remember to add acceptance criteria. Acceptance criteria complement the story’s narrative: They allow you to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story and make it more precise and testable, and they ensures that the story can be demoed or released to the users and the other stakeholders. As a rule of thumb, I like to use three to five criteria for detailed stories.

8 Use Paper Cards

Paper cards are not only cheap and easy to use. They facilitate collaboration: Every one can take a card and jot down an idea. Cards can also be easily grouped on the table or wall to check for consistency and completeness and to visualise dependencies. Even if your stories are stored electronically, it is worthwhile to use paper cards when you write new stories.

9 Keep your Stories Visible and Accessible

Stories want to communication information. Don’t hide them on a network drive, the corporate intranet jungle, or a licensed tool. Make them visible instead, for instance, by putting them up on the wall. A great tool to discover, visualise, and manage your stories is my Product Canvas. SampleProductCanvas

10 Don’t Solely Rely on User Stories

Creating a great user experience (UX) requires more than writing user stories. Also consider the user journeys and interactions, the visual design, and the nonfunctional properties of your product. This results in a holistic description that makes it easier to identify risks and assumptions, and it increases the chances of creating a product with the right user experience.

Learn More

Learn how to write great user stories by attending my Writing Great User Stories Workshop. Please contact me for onsite delivery of the workshop.

[This post was last updated on 28 May 2014.]

“The product manager’s job is to oversee all aspects of a product or service line to create and deliver superior customer satisfaction while simultaneously providing long-term value for the company,” writes Linda Gorchels in the third edition of The Product Manager’s Handbook. This sounds similar to Ken Schwaber’s description of the product owner role in the Scrum Guide: “The Product Owner is the (…) person responsible for (…) ensuring the value of the work the team performs.” So what’s the difference between a product manager and a product owner?

Working as the product owner implies taking on many product management responsibilities including understanding the market, describing product functionality, and preparing the product launch. This makes product managers well suited to play this new role. But a product owner is more than just a re-branded product manager: Product owners tend to take on a wider range of duties, which makes the role multi-faceted and challenging. The following formula captures this insight:

Product Owner = Product Manager + x

My experience suggests that the x above comprises additional strategic duties including envisioning the product and managing the product roadmap as well as further tactical ones, such as collaborating with the development team throughout the development effort, writing user stories, carrying out release planning, and managing stakeholders. Consequently, product owners often require more authority and more focus to do their job well. Note that product ownership is teamwork in Scrum: Requirements are no longer identified and described by one person. Product owner, ScrumMaster and team collaborate on a regular basis to groom the product backlog.

Working as a first-time product owner is hence a new experience and a challenge. The right training and coaching measures can help product owners get up to speed faster. “Early immersion and training of the product owners in agile principles, product backlog creation, user story design and estimation and planning is key to the success of any agile team. Also, beyond initial training, continuous product owner coaching throughout the rollout is necessary to ingrain the new process into the culture,” write Fry and Greene about their experience at Salesforce.com in their article “Large Scale Agile Transformation in an On-Demand World.”

You can find more information on the product owner role, its duties and helpful practices in my book Agile Product Management with Scrum. I also advise and coach product owners. Have a look at my services and get in touch to discuss how they can benefit your product owners.