Tag Archives: product owner

RertoFeaturedImage

The Retrospective in a Nutshell

The sprint retrospective is an opportunity to pause for a short while and reflect on what happened in the sprint. This allows the attendees to improve their collaboration and their work practices to get even better at creating a great product.

The meeting takes place right at the end of the sprint after the sprint review meeting. Its outcome should be actionable improvement measures. These can range from making a firm commitment to start and end future meetings on time to bigger process changes. The retrospective is not a finger-pointing exercise. As Mahatma Gandhi famously said: “Be the change you want to see in the world.”


Take Part

As the product owner, you are a member of the Scrum team, which also includes the development team and the ScrumMaster. While you are in charge of the product, you rely on the collaboration of the other Scrum team members to create a successful software product. If you don’t attend the retrospective as the product owner, you waste the opportunity to strengthen the relationship and to improve the collaboration with them.

TheScrumTeam

But there is more to: Taking part in the sprint retrospective allows you to understand why the team requires some time in the next sprint to carry out improvements such as refactoring the build script, or investigating a new test tool; and maybe more importantly, it helps you improve your own work.

Say that some of the user stories the team had worked on did not get finished in the sprint. At first sight this looks like the development team’s fault. But analysing the issue may well reveal that the size of the stories and the quality of the acceptance criteria contributed to the problem. As you are responsible for ensuring that the product backlog is ready, this finding affects your work: It shows you that you have to decompose the user stories further and it suggests that the development team’s involvement in getting the stories ready should be improved – otherwise you would have spotted the issue before the stories went into the sprint.

If you had not been in the retrospective would you then whole-heartedly support the resulting improvement measures and change the way you work?


Be an Active Participant

Don’t attend the retrospective as a guest who will speak when asked but otherwise remains silent. Be an active participant, use the sprint retrospective to get feedback on your work, and raise any issues that you want to see improved. Be constructive and collaborative but don’t shy away from tough problems.

POAsActiveRetroAttendee

Here are some questions that you may want to explore in the retrospective:

  • Do you spend enough time with the development team? Are you available to answer questions or provide feedback quickly enough? Do you provide the right level of feedback and guidance in the right way?
  • Is the communication between the team and you open, honest, and trustful?
  • Does the team know how the users employ the product?
  • Are the team members happy with their involvement in analysing user feedback and data, changing the product backlog, and getting stories ready for the sprint? Do you get enough support from the team to “groom” the backlog?
  • Are the team members aware of the big picture – the overall vision, the product strategy, and the product roadmap? Do you get enough of the team members’ time to help you with product planning and product roadmapping?

Improve the Wider Collaboration

As important as it is, continuously improving your collaboration with the development team and the ScrumMaster is usually not enough. You also need strong relationships with all the other people required to make the product a success. These include individuals from marketing, sales, customer service, finance, and legal, as the following picture shows.

POWiderCollaboration

A great way to review and improve the collaboration with your partners from marketing, sales and so forth is to invite them to the retrospective on a regular basis. Depending on how closely you collaborate, this may range from once per month to once per major release. A joint retrospective will help you develop closer and more trustful relationships, help smooth the launch of new product versions, and improve selling and servicing the product.

Here are some questions that you may want to explore in an extended retrospective:

  • Are the partners from marketing, sales etc. involved enough in the product planning and roadmapping activities?
  • Do they regularly participate in the sprint review meetings? Are the review meetings beneficial for them? Do they understand the project progress?
  • Do they receive the information necessary to carry out their work in a timely manner, for instance, to prepare the marketing campaign and to compile the sales collateral?
  • Do you get enough data and support from the partners, for instance, regular updates on the sales figures and the market feedback you require?

You can, of course, also discuss these questions one-on-one. But getting any issues on the table and discussing improvement opportunities creates a sense of we-are-all-in-this-together; it reaffirms the need for collaboration and teamwork to provide a great product; and it can break down departmental boundaries.


Learn More

You can learn more about the sprint retrospective meeting and the product owner by attending my Certified Scrum Product Owner training course. Please contact me if you want me to teach the course onsite or if you would like me to run a product owner workshop at your office.

ProductOwnerScrumMasterFeaturedImage

Product Owner vs. ScrumMaster

The product owner and ScrumMaster are two different roles that complement each other. If one is not played properly, the other suffers. As the product owner, you are responsible for the product success — for creating a product that does a great job for the users and customers and that meets its business goals. You therefore interact with users and customers as well as the internal stakeholders, the development team and ScrumMaster, as the following diagram shows.

ProductOwnerRelationships

The grey circle in the picture above describes the Scrum Team consisting of the product owner, the ScrumMaster and the cross-functional development team.

The ScrumMaster is responsible for the process success — for helping the product owner and the team use the right process to create a successful product, and for facilitating organisational change and establishing an agile way of working. Consequently, the ScrumMaster collaborates with the product owner and the development team as well as senior management, human resources (HR), and the business groups affected by Scrum, as following pictures illustrates:

ScrumMasterRelationships

Succeeding as a product owner requires the right skill set, time, effort, and focus. So does playing the ScrumMaster role. Combining both roles – even partially – is not only very challenging but means that some duties are neglected. If you are the product owner, then stay clear of the ScrumMaster duties!


What the Product Owner should Expect from the ScrumMaster

As a product owner, you should benefit from the ScrumMaster’s work in several ways. The ScrumMaster should coach the team so that the team members can build a great product, facilitate organisational change so that the organisation leverages Scrum, and help you do a great job:

ExpectationsOnTheScrumMaster

The following table details the support you should expect from the ScrumMaster:

Service Details
Team coaching
  • Help the team collaborate effectively and manage their work successfully so that they can make realistic commitments and create product increments reliably.
  • Encourage the team to work with the product owner on the product backlog.
  • Ensure that the team has a productive work environment.
Organisational change
  • Work with senior management, HR and other business groups to implement the necessary organisational changes required by Scrum.
  • Educate the stakeholders about what’s new and different in Scrum, explain their role in the agile process, and generate support and buy-in.
  • Resolve role conflicts such as product owner vs. product manager and product owner vs. project manager.
Product owner coaching
  • Help the product owner choose the right agile product management techniques and tools.
  • Support the product owner in making product decisions and tackle product owner empowerment issues.
  • Help establish agile product management practices in the enterprise.

The ScrumMaster supports you as the product owner so that you can focus on your job – making sure that the right product with the right user experience (UX) and the right features is created. If your ScrumMaster does not or cannot provide this support, then talk to the individual, and find out what’s wrong. Don’t jump in and take over the ScrumMaster’s job. If you don’t have a ScrumMaster, show the list above to your senior management sponsor or to your boss to explain why you need a qualified ScrumMaster at your side.


What the ScrumMaster should Expect from the Product Owner

It takes two to Tango, and it’s only fair that your ScrumMaster has expectations about your work as the product owner. The following picture illustrates some of them:

ExpectationsOnTheProductOwner

The table below describes the ScrumMaster’s expectations in more detail:

 Service  Details
Vision and Strategy
  • Provide a vision to the team that describes where the product is heading.
  • Communicate the market, the value proposition and the business goals of the product.
  • Formulate a product or release goal for the near to mid term.
Product Details
  • Proactively work on the product backlog. Update it with new insights and and ensure that there are enough ready items.
  • Provide direction and make prioritisation calls.
  • Invite the right people and choose the right techniques to collect feedback and data, for instance, invite selected users the review meeting and carry out a usability test.
Collaboration
  • Be available for questions and spend time with the team.
  • Buy into the process and attend the sprint meetings.
  • Manage the stakeholders and make tough decisions; say no to some ideas and requests.

You can find more a more comprehensive description of the product owner duties in my post “The Product Owner Responsibilities“.


Learn More

To learn more about the collaboration between the product owner and the ScrumMaster attend my Certified Scrum Product Owner training course. Please get in touch if you have in questions or if would like me to teach the course on-site.

If you feel that your ScrumMaster would benefit from improving her or his work, then I recommend Geoff Watt’s book “ScrumMastery: From Good to Great Servant Leadership”.

TheListeningResourceSusanEliot

Have a Clear Research Goal

Collecting the right data and analysing it effectively requires a clear research goal – understanding the reason why you carry out the work, and what you want to achieve. At the early stages of creating a product, your goal is likely to validate a critical assumption. This could be the product’s value proposition, the main revenue source, or an aspect of the user interaction design. Lean Startup captures the research goal as a hypothesis, and Scrum as a sprint goal.

Without a research goal you are in danger of collecting the wrong data, drawing the wrong conclusions, and moving your product in the wrong direction. In a sense, you are just trashing around hoping that the data will magically tell you what to do.


Separate Data Analysis from Data Collection

Once you have gathered the relevant data – for instance, by observing users, demoing a prototype, or tracking user behaviour using an analytics tool – step back, and carefully reflect on it before you make any decisions.

If you come from a Scrum background, then separating analysis from data collection may be new to you. In Scrum, data is traditionally collected and analysed in the sprint review meeting without always clearly separating the two activities. This carries the danger of rushing or skipping the analysis work, and making suboptimal or wrong decisions.

I hence recommend that you first collect the relevant data and then analyse it. Use the new insights to change the appropriate artefacts, for instance, your Vision BoardProduct Canvas, or product backlog, select a new research goal, and start the next cycle.


Keep an Open Mind

Keeping open mind may sound trivial, but clinging to an idea – not the lack of a fancy analysis technique or tool – is the biggest barrier to drawing the right conclusions in my experience. I know what I am talking about: When working on a new product, I feel strongly about my own ideas, and I sometimes have a hard time changing my mind. But being too attached to an idea, or being too eager to succeed carries the danger of rejecting any data that challenges it, which may well result in a poor product.

Before you carry out any analysis, take a deep breath and relax. Whenever you get tense or worked up about the data, tell yourself that it is not you, who is being challenged, but ideas, assumptions, and concepts. And ideas, assumptions, and concepts don’t have any pride; they don’t want to be right or wrong. They are just thoughts.


Mitigate Cognitive Biases

My fourth tip is to be aware of the cognitive biases we all have. A cognitive bias is a fault in our thinking causing us to draw the wrong conclusions. Confirmation biases, for instance, is the tendency to search for or interpret information in a way that confirms our preconceptions, and self-serving bias is the tendency to claim more responsibility for our successes than our failures.

Maybe the worst thing you can do when employing a framework such as Lean Startup or Scrum is to run iteration after iteration only to look for data that confirms your ideas – and to reject the rest. This is likely to result in late failure, which is just as painful as in a traditional, sequential approach.

A great way to mitigate cognitive biases is to analyse the data collaboratively. This tends to balance out individual preferences, believes, and preconceptions. Consider therefore involving the development team in the data analysis, particularly when you validate critical assumptions.


Clean the Data

Don’t forget to clean the data. Remove data whose quality is too poor to interpret it correctly, and discard irrelevant data. This should be easy enough – unless it’s an idea from an important customer or a powerful stakeholder. But saying yes to every idea is not going to result in a great product but in a cluttered piece of software with a poor user experience. As Steve Jobs once said:

Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features.

Stay true to your vision, and leverage your primary persona to determine the right features.


Pivot or Persevere

When analysing the data, ask yourself if it invalidates your strategy, for instance, the customer segment chosen, the product’s value proposition, the anticipated user experience, or the revenue source. If it does, pivot and change your strategy. This typically requires big amendments of your planning artefacts including the Vision Board and the Product Canvas. If your strategy is valid, persevere and refine the appropriate documents.

Pivoting is never easy, as it require us to accept failure, and to let go of assumptions and ideas we may have grown fond of. But it is often a necessary step towards developing a great product. If you find failure scary, then don’t take it personal, and don’t identify yourself with your ideas: It is not you who has failed, but an idea or an assumption has turned out to be wrong. That happens even to the likes of like of Einstein who famously said:

A person who never made a mistake never tried anything new.

But if you keep pivoting repeatedly, stop and reflect. Check if you are really moving towards a successful product, or if you are chasing an ever-changing dream.


Learn more

While there is more to data analysis then I can cover in this brief blog post, I hope that the tips above help you analyse your data and create a great product.

To learn more attend my Agile Product Planning training course. Please contact me for delivering the training course onsite, and in form of interactive virtual training sessions.

Picasso_Pablo-Nusch_luard

As the product owner you should look outward to the market, and inward to the team and the stakeholders – similar to a cubistic Picasso portrait where the person’s eyes look in two different directions, as the following picture shows:

PicassoProductOwner

The picture above is based on Pablo Picasso’s portrait of Nusch Éluard. Picasso created the painting in 1938 using charcoal and pencil on canvas.

The Outward View: Users, Customers, and Competitors

As the product owner, you should be first and foremost concerned with understanding the needs of the users and customers, and figuring out how well your product is meeting them. Helpful techniques to test your ideas and acquire the necessary knowledge include observing users, conducting user interviews, carrying out product demos and users tests, and employing MVPs. You should hence “get out of the building,” as Steve Blanks puts it, and engage with users and customers. Don’t blindly trust the opinions of senior management or the sales group. Use data to validate your assumptions.

Don’t forget to pay some attention to the competition, and the overall market developments. Even a company like Apple cannot afford to ignore their competitors, as the latest iOS release shows: Some of its new features, such as killing an app by swiping upwards, had been available on other devices.

The Inward View: Team and Stakeholders

While the users and customers should be your number one priority, creating a great product requires the product owner to closely collaborate with the development team. This collaboration is essential: It provides direction to team, and it leverages the team’s creativity and knowledge. Helpful techniques include jointly carrying out the research/validation work such as product demos and users tests, and updating the Product Canvas or backlog together.

As important as it is, collaborating with the team is not enough – particularly in larger organisations. Take into account the interests and needs of the internal stakeholders including senior management, marketing, sales, service, operations, and other business groups. Involve their representatives early and regularly, for instance, by inviting them to review meetings. This allows you to align the stakeholders, and to benefit from their ideas and knowledge.

Make sure, though, that you own the product and have the final say about what gets done. Avoid the trap of becoming a feature broker – someone who negotiates compromises between the stakeholders. Great products are not created by determining the smallest common denominator, and a product that tries to please everyone is likely to please no one. Follow your vision instead, and test your ideas with actual users.

Summary

You certainly don’t have to become a world-renown painter to be a good product owner. But to create a successful product, you should keep a firm eye on the market while collaborating with the development team and the internal stakeholders. Balance the two aspects, and avoid neglecting any for a longer period of time. In doubt, focus on understanding the user and customer needs and how to best address them. Leverage the ideas of the team and the stakeholders. But follow your vision, and validate your ideas early and frequently.

You can learn more about becoming an effective product owner by attending my Certified Scrum Product Owner training course.

OverviewOfTheProductOwner

The product owner plays a key part in bringing new products to live and enhancing existing ones. But many organisations struggle to apply the role effectively. One reason for this is a wrong or partial understanding of the product owner responsibilities. This blog post shares my insights. I hope that it helps you apply the role successfully.

The post is based on an interview Kristin Runyan and Sondra Ashmore conducted with me for their upcoming book. It was last updated on 4 November 2013.

Overview

The product owner is the person who owns the product on behalf of the company. The individual is responsible for the success of the product, and has to be empowered to make the necessary decisions. The product owner should understand the user and customer needs and the business goals, and collaborate with the development team and the stakeholders, as the following pictures illustrates:

A Context-sensitive Role

It is important to understand that the application of the product owner role varies in practice. It is influenced by several factors including the market, the product lifecycle stage, and the organisation. For instance, working as a product owner of a brand-new mobile app developed by a small team in a mid-size company will differ from looking after an existing healthcare product, which is developed by several teams in a large enterprise.

In the early lifecycle stages when the product is developed and introduced to the market, the product owner should act as an intrapreneur, an entrepreneur within the enterprise, as the following picture shows:

As the product matures, the entrepreneurial aspect of the product owner work declines and a  focus on maximising return on investment (ROI) is usually required. As a consequence, there is no one right way to apply the role.

Product Success

The product owner should be responsible for the success of the product. But what does this mean? A successful product does a great job for its users and customers, and it benefits the organisation developing it, as the picture below illustrates. Sample business benefits include entering a new market or market segment, meeting a revenue target, and strengthening the brand.

A great way to determine the product success is to carry out some customer discovery or problem validation work including business modelling. Tools like the Vision Board, the Business Model Canvas, and the Lean Canvas help you determine what success means for your product.

Responsibilities

Product owners should take on the following strategic and tactical responsibilities:

ProductOwnerResponsibilities

Techniques such as user observations, problem interviews, competitor analysis, business modelling, product roadmapping, personas, user stories, scenarios, design sketches, product demos, user tests, metrics and analytics, and release planning usually help the product owner do a great job. But be aware that you have to choose the right techniques and tools for your product depending on the factors discussed above. Business modelling, for instance, is an important skill for product owners of a new product, but less beneficial when working with a mature product.

Wrap-up

The product owner role is a multi-faceted job that requires a broad range of skills. But it provides the exciting opportunity to create something new, to develop new products and features that benefit the users and the organisation. It’s a fascinating and rewarding job in my mind.

You can learn more about the product owner responsibilities by attending my Certified Scrum Product Owner training course.