Tag Archives: product owner

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.

NPDProcessLeanStartupScrum

Discovering Lean Startup was inspiring for me: I felt I had found an approach that could complement Scrum nicely. Since then I have been combining the two approaches in my own new product development work as well as helping my clients to do so. This post shares my experiences and insights. It maps out a high-level process for creating new products within existing businesses focussing on product management practices and tools.

From Vision to Launch

Lean Startup encourages us to first investigate if there is a need worthwhile serving before we worry about the details of the new product. The former is called “Problem Validation”, the latter “Solution Validation”. While traditional approaches also suggest carrying out market research and analysis before we engage in product planning and definition, lean approaches increase the speed at which we operate. This allows us to fail and learn faster, to adapt our product strategy and tactics quickly, and to hopefully launch the right product with the right features sooner.

The following diagram illustrates the process I apply to create new products:

Problem Validation

The new product development process depicted above starts with a vision. It then uses a series of cycles or iterations to transform the vision into a product ready for launch. The focus of the early iterations is to understand what problem the product solves, who the customers and users are, and how the product benefits the company creating it.

I find it important that the product owner leads this effort and carries out the necessary work together with a cross-functional team. While the team composition depends on the product, having a marketer, sales representative, service representative, a UX designer, and a developer on board is usually helpful. Product owner and team capture their assumptions about the market by using a tool like the Vision Board, Business Model Canvas, or Lean Canvas.

Employing techniques such as direct observation, problem interviews, and competitor analysis helps them validate their assumptions and update the board or canvas, as the following pictures illustrates:

Additionally, the developers may create spikes (throwaway prototypes) to explore the feasibility of the product. Target users and customers participate in the process, for instance, by acting as interview partners.

Solution Validation

Once product owner and team have shown that there is a problem that’s worthwhile addressing, the focus changes to validating the solution and developing the actual product: The team needs to learn what the desired user experience is, what functionality the product should provide, and how it should be built.

The new focus requires adapting the team composition: The product owner, the UX designer and the developer stay, but the marketer, sales and service representatives leave the team. They continue to participate in the development effort as stakeholders. New developers, testers, and other roles required to create a great product join the team.

Product owner and team capture their assumptions about the product including the user interaction, the user interface design, the functionality, and the nonfunctional aspects using a tool like the Product Canvas and techniques such as scenarios, user stories, and design sketches. The assumptions are tested by collecting and analysing feedback on prototypes, mock-ups, and product increments/MVPs. Useful techniques to gather the feedback include product demos, users tests, and releases (to selected users).

As you may have noticed, the picture above suggests that “Stakeholders incl. users” participate in the process, and provide feedback or data on work results. While using target users and customers to validate ideas is generally helpful, it is not always appropriate. Imagine addressing a key technical risk in your first solution validation iteration: It probably makes little sense to invite users to the review meeting to understand if the approach chosen is viable. Similarly, if a disruptive product is developed it can be hard to find target users that are not too attached to their current solution.

Scaling and Launch Preparation

Once the Product Canvas and the architecture have started to stabilise, you can start adding more people to the project. I find it useful to break-up the original team so that at least one or two members are part of each new team, as this helps the new members get up to speed. I also suggest you grow your new product development project in a step-wise fashion: Scale from one to two teams, then from two to four, and so forth. This allows you to understand the impact on the people and the process including product ownership .

Be aware of the danger of premature scaling: Adding too quickly too many people. This tends to lead to a bloated, over-engineered product in my experience, and it prevents you form being able to experiment effectively. Therefore delay scaling until you have resolved the main risks – until you can focus on completing features and adding new ones.

Finally, as you make progress with your solution validation work, don’t forget to prepare the product launch. Having a marketer present at the sprint review meetings should help, but you may find that a dedicated marketing may be required to prepare and execute the launch well.

Summary

The following table summarises my recommendations for transforming an idea into a shippable product:

The process described in this post is based on work by Steve Blank, Ash Maurya, Eric Ries, and Ken Schwaber. The eagle-eyed process historians amongst you may have noticed that the idea of progressive scaling has its roots in the (Rational) Unified Process. Experimental, iterative product development has been around for quite some time of course, I believe at least since the late 19th century when Thomas Edison established the Menlo Park laboratory.

You can learn more about combining lean and agile techniques to create new products by attending my Agile Product Management training course. Please contact me for onsite workshops.

If you have any feedback, comments, or questions, then I’d love to hear from you!