This post is the second of a three part series on Scrum roles and their part in innovation. This post looks at how the product owner uses a north star of business value to guide what gets built. The first blog in the series looked at How the ScrumMaster Helps Create a Better Alignment Between Innovation Goals and Business Needs. The last post in the series is about how Technical Leadership owns the “How” of building shippable increments.
While all team members are vital to successful product development, when it comes to developing innovative software, your product owners are arguably the most critical to this success. While delivery is a shared responsibility, the product owner is the absolute owner of the product’s vision and requires critical thinking to be able to map out the route to delivering value.
More than Just a Backlog Administrator
Strong product ownership implies both a specific skillset and mindset. The product owner does much more than just administer a backlog. They are your embedded business representative within the team, ultimately responsible for what gets built. Product owners understand the goals of the business and why the product was envisioned, and they are able to translate that into clearly defined functional components, which they keep prioritized by business value through the lifecycle of the product development.
True product owner innovation requires honed critical thinking and problem-solving skills. Product owners must be able to define the problem that the product will solve, identify who would benefit from the product, and how they would benefit. Sometimes, though rarely, this identification is made based on their own intimate knowledge of the market needs and competitive landscape. More often this information is gathered through pointed and thoughtful conversations with the stakeholders and subject matter experts. Only at this point, the big picture is understood.
Identifying Points of Value Delivery
Then comes the hardest part. The product owner must take the envisioned big picture and break it into independently shippable features and user stories to form an executable backlog. In following the agile methodology this can be tricky because each user story must on its own deliver business value. Why? Put yourself in the shoes of the stakeholder. Imagine you just finished a sprint review and the stakeholders ask, “OK, so can we get this out to customers to start getting feedback?” You want to be able to say, “Yes, we can ship this whenever you want!” If you don’t write user stories as independently shippable features you will not have the ability to ship when it provides the most value to your stakeholders. Read more about developing shippable increments in our definition of done blogpost.
In addition to maintaining a backlog of user stories that are written in a shippable manner, the backlog must be prioritized in order from most to least business value. This is where the critical thinking skillset of the product owner comes in. They must be able to look at the envisioned product and identify where the points of value delivery exist. Prioritization is more than just delivery order, though. The product owner also owns the ROI of the development team. So, prioritization happens not just with backlog ordering, it also happens constantly in the form of both team level and stakeholder negotiations. At the team level, they look for stories or even tasks that are estimated to take a lot of effort. They constantly weigh effort against value, and negotiate within the team to ensure the two are balanced, and that the team is spending its time on the most valuable items at any given time. At the stakeholder level, the product owner negotiates scope by way of having the stakeholder(s) prioritize functionality into categories of Must Haves, Nice to Haves, and Someday/Maybes. This keeps everyone on the same page for Minimal Viable Product (MVP) scoping. Need a refresher on MVP? Read our blog post on the topic.
Accountable to Stakeholders
The product owner is the team member responsible for demonstrating accountability to the stakeholders. They are in charge of both demonstrating the work that has been completed at the end of every sprint, and they also answer for any features that have been missed. Because they are accountable to the stakeholders, within the team they have the sole ability to decide if work is “done”. A gatekeeper of sorts, they are the sole approver of any completed development.
Incremental delivery is everything in Innovation
Markets move quickly. Sometimes, a six or twelve month development project timeframe is simply too long and risky, especially in a competitive landscape where the market may be untested or the technology or solution is a market disruptor. In these cases, being first to market might be crucial to success. Flexibility in product release dates is vital.
When agility and flexibility in release timing are so critical, strong product management and product ownership becomes a success driver. The product owner’s ability to understand the what and why behind the true minimum feature set that solves a market problem, and their ability to develop a backlog that supports the release strategy for those crucial components, are the path to which innovation ideas become real. It is only by way of ruthless prioritization and rigorous acceptance testing of features that projects stay lean and achievable. With everything always in a “done” state, the business can, in fact, release at any time. So, if market demands a faster timeline, perhaps an early prototype to a few target users, the product owner can help cut scope to get a slimmer version out sooner.
Technical Prioritization
A critical piece of development speed is tied to infrastructure. Infrastructure setup can make or break a project. In large companies, this can be an arduous process, slowing delivery and crippling the ability to respond to market demands. While the product owner may not be technical, in an ideal Scrum team setting, they work with the Technical Lead or Architect to right size the infrastructure to the needs of the release. For example, if you know you are just going to pilot a new software with a few customers, then the infrastructure does not need to support general availability with guaranteed business continuity. Skillful product owner innovation requires exposure to business needs and release plans, as they are critical to driving development decisions. We’ll dive into this topic in the final blog post of this series.
