17 December 2015

The Case of the Missing Product Owner

I’ve been doing some research about our history at Gaslight. We’ve worked on almost 100 different software projects over the past six years which works out to about 16 projects per year. Out of those 100, we can count the unsuccessful projects on one hand. And that means we’ve delivered more than 95% of our projects with valuable working software and happy clients.

It’s a track record that makes me proud, but it also presented a mystery: What’s the biggest factor in success? This question sent me digging through our old projects, and pretty quickly, I discovered the case of the missing product owner. Let’s take a look at two real Gaslight projects to see how the presence–or absence–of this key team member affects project outcomes.

Project A: No Clear Product Owner

Project A was a risk from the beginning. Several people involved in the sales and on boarding process agreed that there were red flags. No clear decision maker. Uncertainty about business objectives. And a desire to use technical tools based on their popularity on technology forums. In hindsight, we should have stopped the process right there and suggested coaching or another alternative.

Instead, we decided to take the project on. Meetings were frequent and seemingly directionless. The team was large and roles were unclear. We seemed to make decisions together, but once we started working again, it was like those discussions had never happened.

We struggled to establish good communication channels. Sure, we had chat tools and project management software, but they didn’t seem to have the right effect: Keeping everyone informed and on the same page.

There were no users for the first few weeks. A couple months later we still didn’t have any users. There was nothing to test and no one to test it. No one offered clear guidance about what tasks the product needed to perform or how it made the client’s or end users’ lives easier. Features were designed by committee and guessing.

We failed to establish milestones, too. It was hard to know whether we were making progress or just performing activities. Developers and designers worked alone, causing issues when it came time to merge code or bring different pieces of functionality together.

Ultimately, we both agreed that the engagement was not successful. We discussed how things might have gone better, but one of the key takeaway was lack of direction. We needed a leader.

Project B: A Strong Product Owner

Project B was full of enthusiasm from the beginning. We were excited about the goals of the project and aligned on the overall vision. We’d also clearly established who the product owner was and how much time he’d spend working on the project. In fact, this product owner moved right into our office and spent the majority of his time right next to our designers and developers.

This product build quickly developed a regular cadence around delivery. Features that were moved to acceptance were tested in a very short amount of time–sometimes within just a couple of hours.

The product manager spent half their time working with the development team and the other half engaging users. They conducted user interviews and watched real people use the app. Every chance possible, this product owner asked real users how we could improve the product and create more value. The client invited us to those sessions, too.

There were weekly planning meetings using our story map as a guide. Questions and decisions were focused on the work in progress, often avoiding longer term concerns that weren’t relevant to our short term goals. This product owner asked for guidance when needed and valued ideas from all team members, regardless of title or role.

Teams and meetings were kept small and focused. The product owner made sure everything we worked on was designed to create the outcome we wanted for users.

What We’ve Learned

In our experience, a strong product owner is absolutely essential to building great software. Product owners are the CEO of a digital product. They’re tasked with turning abstract business strategy into real revenue generating products. This role requires vision, communication and facilitation skills and decisiveness.

The best product owners understand that the best teams are small teams. Usually, no more than 4 to 6 people from different disciplines. There is clear authority, and when decisions have to be made, the product owner commits to them.

As more companies innovate and automate by building software, there’s a shortage of great product owners. We’re going to do a series of posts on what it takes to do this job well, and we hope to launch some workshops next year, too. Stay tuned!

Heads up! This article may make reference to the Gaslight team—that's still us! We go by Launch Scout now, this article was just written before we re-introduced ourselves. Find out more here.

Related Posts

Want to learn more about the work we do?

Explore our work

Ready to start your software journey with us?

Contact Us