It's about time

My last two years at Fitness24Seven I've been working in the role of Product Owner for our digital services. Never before have I worked with software projects where the product owner had software delivery experience. So I would like to share my thoughts on product ownership.

It's about time.

You are the Superhero!

You have a magic abilily to create time. Nobody else in the team can do this. A good project manager can save time, without making too many tradeoffs, but the product owner can create time out of thin air.

For a medium sized project of 3000 hours, there are lots of requirements and expectations. Your team will have to work 4 months to create the final product, but as you are aware lots of things may happen in 4 months. The only way to reduce the risk is to split the project into smaller parts.

As a product owner you split the project into two projects of each 2000 hours. You have now created 1000 hours without increasing the amount of work. What happens when you split work into smaller pieces is that you discover that you didn't know all the details before. You have discovered work that wasn't accounted for but still expected to be done within the 3000 hours.

A 2000 hour project is still a large project so you split it into two 1250 hour projects, and so it goes until you have found the smallest deliverable projects. You take all of your projects to the business people and ask them, "which one of these will provide most value to the business", and then you start working on that.

By reducing the size of the deliverable you have not only reduced the risk of the project, but also made sure that the value will be available to the business earlier, and you have created enough time for the team to make a good product. This is your superpower!

The smaller the better

Once you've found your appetite for dividing projects into smaller deployable things there is no end to it. You start splitting user stories into smaller deployable pieces in order to deliver sooner (not faster). The new functionality generates more value, as you get it to your users earlier.

When we start splitting user stories we do not split it into frontend and backend parts. We split the work into complete vertical slices of functionality. Instead of building an e-shop we will start by delivering a product catalogue. Next we deliver the ability to buy and pick up at a service point. Next we deliver shipping option with a shipping partner.

By developing and delivering in small chunks we also learn continuously what the users want and can change the prioritization from what we've learned. This improves the value output of your product as you do not have to guess what your customer wants. This would never have been possible with the 3000 hours of fixed scope.

After a while you'll find that projects are too big pieces to deliver at once. You start splitting it into even smaller parts to be deployed weekly or even daily. "Projects" turn into a bureaucracy for budget planning, a ceremonial to keep business people content, while your team deliver value in a continuous stream of functionality.

Scope it down

Your stakeholders will come with wishlists of functionality they want included in your product. The UX designer will create modern digital solutions that your users will love. The backend developers will design a system that will scale to 100 million users.

It is your job to scope it down.

Find the core functionality that will generate value. Remove all the extra finesse and tell your developers to make the easiest solution possible. You will deploy it within days and validate if it did generate expected value. You decide to add that extra UX cruft, deploy and find that users enjoy it. The feature starts to behave sluggish, so you ask your backend developers to make it work for 1000 users. They deploy and your users are happy.

What I have found is when you've delivered the core functionality, there's always something else the business wants you to focus on. Since you work in small chunks this is not a problem and you can change priorities in order to deliver as much value as possible.

Sometimes the core functionality doesn't feel like the feature is done. But it is good enough for now. If there is a need for it to improve you will get back to it later.

How to do this

There are a couple of things you need before you can start doing this.

1. You need to make deployments trivial
2. You need to get your development team in the boat with you
3. The business needs to trust you're doing the right thing
4. You need to approach product ownership as a full time job
5. You need to focus on quality and don't let the team take shortcuts

Reading list

• The Lean Startup, Eric Ries
• Accelerate, Building and Scaling High Performing Technology Organizations by Nicole Forsgren PhD, Jez Humble and Gene Kim
• Get in the boat, Pat Bodin