“A Product Owne, it’s most beneficial form acts like an Entrepreneur, like a ‘mini-CEO’. The Product Owner is someone who really ‘owns’ the product. This is something quite different from a project manager (PM) or business analyst (BA) role, where ‘the business’ typically ‘owns’ the product and where the PM or BA act more like a proxy between the (project) sponsor and the supplier (IT for example). The Product Owner as an Entrepreneur owns the Product, the Product Vision, the Product Roadmap and the Products’ budget. So ideally, the Product Owner is profit-and-loss accountable for the Product.”
You can click any timeline item to see a detailed description in a modal window. When you are using a touch screen, you can swipe through the single items. For all the other visitors, an arrow navigation is available, so nobody is discriminated 😉
First things first; the Scrum Team & the product vision
Forming the Scrum Team & collaborate with them
As a Scrum Product Owner, I only need one thing in order to get started, which is my Scrum Team! I’ll need someone to help me guide the process, coach you and your team and to solve impediments, which is my Scrum Master.
Get clarity on the (product) vision.
There are many tools/techniques that could help you in defining the product vision, take a look at some of these techniques (business model canvas, product vision board, product canvas, value proposition design) and collaborate with your stakeholders, Scrum Master and Development Team to create them. Mind yourself, it would require a perfect and non-changing world to get your first vision board right. Besides that, since the world is changing continuously, you’ll probably have to pivot or change things around over time anyway. So, don’t try to get it perfect! Try to create an inspiring vision, that helps people to focus. That’s an important part of your job as a Product Owner, create focus.
Business Model Canvas
Product Vision Board
Value Proposition Design
As a Scrum Product Owner, I only need one thing in order to get started, which is my Scrum Team! I'll need someone to help me guide the process, coach you and your team and to solve impediments, which is my Scrum Master
Showing a vision and the way to get there.
All team members have a chance to understand the planned project scope. This involves a few questions being answered. For example these:
- what is the goal and in what timeframe do we want to achieve it?
- Who are we doing what we are doing for? (target group of the product and stakeholders)
- What obstacles are there along the way that we should consider?
All team members have a chance to understand the planned project scope. This involves a few questions being answered.
Team building and working methods.
A team works at eye level and solves tasks together – that is the big difference to a group in which tasks are distributed and ticked off. In the kick-off it is therefore important that the team finds itself.
There are two main areas of focus:
- Who is actually in the team? What do the people bring to the table, what are their strengths, weaknesses or even “superpowers”?
- What can we do to be successful as a team? Or in other words: how do we actually want to work together?
Build upon a solid foundation
Once the team is in place, it’s important to remember that agile teams are like individuals: they take time to grow. Agile theorists often quote Tuckman’s “stages of group development.” Agile teams go through four key phases as they develop.
After a team reaches the performing stage, development truly becomes awesome. Members trust each other, understand one another’s strengths, and use that understanding to optimize how they build software.
Keeping agile teams intact takes some organizational discipline, but it pays to protect the team–within reason, of course. When change is introduced (new hire, employee departure, etc.), the team reverts back to the forming stage as it absorbs the change.
High-performing agile teams are also built on sound engineering practices like code reviews, task branching, continuous integration, and regular release cadences. We can’t stress this enough: engineering fundamentals are crucial for building great teams.
There are two other pillars of great agile teams: continuous mentoring and shared skill sets. One of the big benefits in working on a team is that colleagues learn from one another and mentor one another. Mentoring isn’t just an activity for junior members to learn from senior members. Everyone on the team learns from one another so that the impact of the team as a whole is greater than the sum of the impact made by it’s individual members. Meanwhile, shared skill sets unlock the power of the team to tackle heterogeneous work. As engineers, it’s always important to learn new skills because it makes us more valuable to the organization and better equipped to support each other’s work. It also guards against someone becoming a critical path, which takes a load off everyone’s mind.
How agile teams collaborate across departments
Today’s software teams include product managers, designers, marketers, and operations as well as developers and testers. At Atlassian, we focus our agile teams around three product phases: make, sell, and operate.
Each product phase is supported by three teams (ideally 5-7 members each), and forms a triad. Each triad is agile in its approach, because as the product develops, teams are continuously working on each phase and learning more about the product as well as the market. Below is a breakdown of each triad and the who, what, where, and why for each team within the larger software team.
Regardless of which triad your team operates in, agile can make your team deliver faster and have more fun. Dig further into this section and learn how to focus and optimize agile teams.
Triad Who Focus Make Product Management Understand the market, targeted customer personas, and good product design principles Design Define the value proposition, product goals, and minimum viable product Development Develop the product using sound, sustainable engineering practices Sell Product Management Understand the product’s competitive landscape and market evolutions Design Create messaging that highlights the product’s value propositions to each customer segment Marketing Create messaging that highlights the product’s value propositions to each customer segment Operate Product Management Release software to customers with a regular cadence Development Respond to customer issues Support & Op Relay customer feedback to the make triad (Dev, PM, Design) as input for future product development
A team works at eye level and solves tasks together - that is the big difference to a group in which tasks are distributed and ticked off. In the kick-off it is therefore important that the team finds itself.
Subject matter introduction to the project
In the subject kick-off, the product owner or project lead presents the vision and goals to the team. From this, the Scrum team understands what exactly the task is that they are working towards together. In the first step, this is not so different from a “normal” meeting: a presentation prepared by the product owner is shared on the screen.
It is not about translating the analogue 1:1 into the digital, but discovering the new advantages.
But now comes the “highlight of the digital”. Because so that the team can pull together, there is time for questions on every slide. The “virtual marker” is used to highlight areas on the slide that are not understood and then discuss them in the team. A kind of digital finger pointing.
- Keep concentration and motivation high by planning for the session to last no longer than 2 hours.
- All team members test the tool in advance if they are not already familiar with it – on Zoom this can be done via zoom.us/test.
- Select the “tile view” on Zoom, so you always have the whole group of participants in view.
- In moderation, participants are actively invited to contribute their opinions or questions. After all, you can hardly see the gestures and facial expressions of the people. In the digital space, you have to be much more aware of the power of language.
In the subject kick-off, the product owner or project lead presents the vision and goals to the team.
Building a team feeling from home office to home office
Who are the people I am working with? A very important question if you want to use Scrum successfully! After all, you tackle tasks together, use the creative power of the group and want to solve problems together. This requires a basis of trust! In the afternoon session, things get colourful.
Those who think that it is difficult to reach a trusting personal level in a completely distributed team are mistaken.
A MURAL board, i.e. a digital whiteboard, serves as the place for this. A get-to-know-you game is prepared there.
After a short introduction, everyone solves a few small tasks for themselves, for example:
- Attach a profile picture
- Upload a picture of your current workplace
- Write down three things that are important to you.
- These tasks are the basis for exchanging ideas about who actually ticks what. And that leaves room for surprises! For example, at the team kick-off with one of our clients, it turned out that a UuM team member and a person on the client’s side share the same passion for gaming and films – and shared a few remote work hacks directly from this.
Who are the people I am working with? A very important question if you want to use Scrum successfully!
Things to consider during the first meeting
There are a few things to consider during the meeting:
- Since it is the first meeting, it is likely, to begin with, an introduction. To make a better connection,it is a good practice to attach the team’s profiles in the calendar invites. By sending the profiles before the meeting, introduction round goes smoothly and you spend less time on it.
- The first meeting is mostly a meet and greet. To get an insight, I like to ask questions, but I keep it simple. To portray myself and the company, which I represent, as a trusted and credible company to work with. Questions like “When did you come up with the idea? When have you started working on it?” encourages clients to tell their story. After all, it’s not about me but the client and I should regard his vision as if it was my vision.
- Later on in the meeting I go more into the subject and ask questions at a high level. Therefore, I prepare for in-depth questioning from clients side, due to theinformation I have gained before
Therefore, it is important for me, to know know who I am talking with. If they are tech-savvy, I try to involve people who have worked in a similar domain to prove the company’s expertise.
For reserved clients who are not willing to disclose everything, I take the initiative to build trust from my end. I disclose everything from my side, including information that will add value to their solutions. I will Take initiative to trust clients and show my trust, so they can reciprocate with trust.
Some clients may take more time than others but it’s okay. I have worked with many diverse clients and every client is an individual personality. It is my task, to adopt this, because this is iportant for the partnership to work.
Since you are setting the first meeting, it is likely, to begin with, an introduction. So, attach your team’s profiles in the calendar invites. When you send the profiles before the meeting, introduction round goes smoothly and you spend less time on it.
Introductional meeting with customer and stakeholders
Setting up a meeting
Before setting up the meeting, it is important figure out who are the right participants and what is the objective behind it. After the participants are known, a date and time are set and the invitatons to all the participants, with details about the meeting, agenda and any supporting materials that you want clients to have access to, are send.
It is important to clarify the agenda for the meeting to avoid derailments from topics during the meeting.
An agenda set for the meeting is communicated to all the participants. Since it’s the first meeting, the agenda could be about introducing teams, products or simply getting familiar with each other. It is also suggested to share any supporting materials as slides or documents in the calendar description, so they can go through it and spend more time on relevant conversations. Your clients will also have a general idea of what is going to be discussed when you send out slides or documents.
It is important to remove all friction if possible. Testing devices before meetings. I do not want to deal with lagging internet or flaws in the optical and audio devices during meetings. This will surely leave a bad impression on your clients. I don’t leave things because they are obvious, there can be unforeseen issues that can be solved before meetings. Experience has made me rich 😉
Another important task in successfully running your first client meeting is sharing the meeting notes during the meeting. Make sure you inform your client that you are taking notes and share it with them. This helps set some level of transparency between the two parties and also validate assumptions made during the meeting. People might sometimes misunderstand the requirements, and sharing notes with your clients during meetings will allow them to clarify and validate those assumptions.
After the meeting is over, I always send out an email with a summary of what was discussed in the meeting. Email is a scalable communication and can be shared with teams when required. Often the client(s) will need to communicate project details with their team and your notes will save them time. The minutes are also a good way to validate that everyone is working on the same set of assumptions after the meeting.
This checklist prepares me and the company,I represent, to make a good impression from day one. Me as a development partner come in to lead and consult. By successfully running the first meeting I show that I am credible and that I can be trusted with their project. The first meetings lay the foundation of earning trust, credibility and building rapport with the client(s).
Before setting up the meeting, it is important figure out who are the right participants and what is the objective behind it.
Get clarity on the stakeholders and how to engage them.
One of the responsibilities of a Product Owner, is to manage (or engage with) the stakeholders (including customers). He or she should make sure, that the right people are sitting together with the Product Owner, to decide on the product vision, product roadmap, value for the product and to make choices together. The Product Owner, should involve the right stakeholders to maximize value delivered to your customers.
A tool which is used quite often is the ‘stakeholder map’. It’s a nice tool to gain insight in the stakeholder field and to decide how to manage them / engage with them. In the stakeholder map, you can plot your stakeholders on two axes; 1) their (formal/informal) power and 2) their interest in the product.
Based on their power and interest, you can define how to engage with the different groups of stakeholders. So what can be done, is to design a stakeholder map and based on the mapping, a communication strategy is designed for the different groups of stakeholders. Although it may not hbe neccessary to mention this, one will likely spend most of the time on the most important stakeholders. Therefore the communication design strategy is based on this principle.
Get clarity on your mandate (including your team and budget)
So, now that themost important stakeholders are known, they are involved to define your mandate. Maybe the Product Owner has been appointed by a sponsor, management or the business as a Product Owner, but what does this mean for them? What are the Product Owner’s responsibilities? And what is the mandate that comes with these responsibilities?
A great tool, to get clarity on the Product Owners’ mandate, is Jurgen Appelo’s (author of Management 3.0) Delegation Poker . There are quite some examples of Delegation Boards / Delegation Poker that can be found on the internet, also see the following example. There are some aspects that I always like to get clarity on (amongst lots of others), which are:
- Who is needed to define, change or pivot the product vision?
- Who is needed to define, change, pivot or remove business goals?
- Who is needed to add, define, change or remove items from the Product roadmap?
- Who is needed to add, define, change or remove items from the Product Backlog?
- Who is needed to add, change or remove people from the Scrum Team?
Why a traditional Delegation board doesn’t work
One of the popular practices of Management 3.0 is the use of Delegation Boards. In a delegation board, you describe which delegation level is applicable for a key decision area (KDA). The seven levels are:
- Tell, the manager decides.
- Sell, the manager decides and tries to sell their decision to the team.
- Consult, the manager asks input from the team before the manager makes the decision.
- Agree, the manager and team agree together on the decision.
- Advice, the team asks input from the manager before they make the decision.
- Inquire, the team makes the decision, and try to sell this decision to the manager.
- Delegate, the team makes the decision. If necessary they will inform the manager.
Determine what ‘value’ is/means for “my” product
How to define and measure value is something that is context-dependent. This may be totally different depending on the product, type of product, product lifecycle phase, etc, etc. Therefore, one should define together with the (most important) stakeholders, what you consider as ‘value’. What is ‘valuable’ for the product? What is valuable for the customers? What is valuable for the processes which are supported? Based on how the values are defined for the product, one can also decide how to determine the measure value for the product.
Please remember, what value for a particular product is context dependent. However, what value is, is also time-dependent! What value is for a particular product and how to measure it, may change over time. This needs agility.
One of the responsibilities of a Product Owner, is to manage (or engage with) the stakeholders (including customers).
Create a (goal-oriented) (product) roadmap
Now that te value of the product has been defined defined and also how to measure value, it’s a good time to translate this into a goal-oriented product roadmap. The goal-oriented roadmap is awesome, since it is focussed on value (goals) first and features later.
A lot of Product Owners fall into the trap of maximizing the teams’ output. The goal should however be to maximize outcome. So, one should start by focussing on goals first! By defining a couple of goals for the shorter term (next Sprint, this month, next month) and for the longer term (this quarter, next quarter, this year). Ordering and managing the Product Backlog will become much easier if the goals are transparent.
Create a story map for the product.
The next step would be to create a story map, together with some of your stakeholders and your Development Team. The story mapping technique is an awesome way to brainstorm, gain insights and get a picture of the product you are creating.
Now that te value of the product has been defined defined and also how to measure value, it's a good time to translate this into a goal-oriented product roadmap.
Co-creating the Sprint Goal & the Sprints’ plan.
Now that a roadmap and story map are created, it’s time to design a Sprint Goal. The Sprint Goal is very helpful, because it provides the Scrum Team with a lot more focus. Focus is not only one of the core values of the Scrum Framework, it also makes a huge difference for the performance of the Development Team, and herewith also for the amount of business and customer value you can deliver for your product.
It is a good approach, to create a ‘concept’ Sprint Goal before the Sprint Planning, with which the Scrum Master assists the Product Owner by asking lots of questions and by brainstorming together. The reason that is is called ‘concept’ is because the Sprint Goal is being created during the Sprint Planning, together with the whole Scrum Team. It makes the sprint planning much more convenient, to start the Sprint Planning with a goal in mind, to reshape that goal with the Development Team and then to move on to the other aspects of the Sprint Planning meeting.
Now that a roadmap and story map are created, it's time to design a Sprint Goal. The Sprint Goal is very helpful, because it provides the Scrum Team with a lot more focus.
Keep collaborating with your Scrum Team and stakeholders
While Sprinting, and while regularly delivering done product increments, the most important thing for you to do as a Product Owner, is to keep collaborating with your Scrum Team and your stakeholders. Support the Development Team by hosting refinement sessions, explaining the product vision, goals, roadmap and Product Backlog items. Support them by making items small, clear and valuable. Support them in gathering feedback from customers and users, etc.
Also keep collaborating with your stakeholders. Make sure to spend the most amount of your time on your most important stakeholders. Update your stakeholder map once in a while. Evaluate if your communication strategy is still working. And most important, make sure you get feedback early and often, so that you can maximize the value delivered every Sprint, again and again!
While Sprinting, and while regularly delivering done product increments, the most important thing for you to do as a Product Owner, is to keep collaborating with your Scrum Team and your stakeholders.