How Shared Ownership Revolutionizes Product Development

In my many years working in product management, I’ve seen and worked with many types of engineering teams. Some teams were large (100+ people), some were small (five people), and many were remote (India, China, Russia, Canada, etc.).

The one constant: The best products were created when engineering and PM teams were the happiest work couple in the company.

To build a successful product, engineers, and product managers must work together to gather key ideas and input from sales, marketing, support, customers, partners, and prospects. The relevant bits and pieces from all these areas need to be molded together to build something that’s needed and used every day. Something that solves a real problem.

So where do you start?

Ownership. Typically, product managers are the owners. I’ve even heard that product managers are like mini-CEOs for their product. I agree with that in some areas, but I also believe ownership should be shared between PM and engineering.

The most effective ownership structure I’ve seen is to have PM and an architect or director of engineering serve as co-owners of a product. This creates a single point of contact in both engineering and PM. Both “OWN” the product (or a specific feature). These two individuals must work together as a happy couple.

With a shared ownership approach, engineering and PM must do many things together. If a customer is angry, the happy couple needs to meet with them, discuss their problems and find a resolution. If usability testing is required, the happy couple must watch customers interact with their product together.

Together, PM and engineering hear firsthand what is great about their product, what isn’t so great, and what customers and the market are demanding.

When only PM sits in on calls with customers and usability tests, there is a communication disconnect. Information and context can slip through the cracks. Subtle things like body language and facial expressions need to be seen firsthand in order to truly resonate.

We are currently building a great feature into BetterCloud that will change the way IT admins manage cloud applications. After early UI mockups and initial user testing, our engineering team got to work. Shortly after we began our second round of usability testing we received awesome feedback that required us to make some significant changes. We needed to make the feature easier to use.

Because they witnessed the usability tests firsthand, there was no push back from engineering to scrap what they had started (not that engineering would ever push back when PM changes things). There was also no push back from PM with the new time estimates from engineering (not that PM gets upset when dates change). Everyone was on the same page.

Doing these activities together allows us to be more agile. We can fail fast on a poor design, right the ship, and quickly build out a simpler UI for our customers.

On another call, a great idea came up from the customer. It sounded hugely complicated, but we knew it would be a killer feature that would set us apart from the competition.

Having the engineering team hear what the customer wanted–and why it would be beneficial–inspired them to think creatively. Because engineering saw the value firsthand, they were excited to tackle the challenge. I have seen many engineering teams shy away from big complicated tasks. But in this case, since the benefit was clear, they dug right in and figured it out.

Today, all of our PMs have a peer in engineering. We’ve also restructured desks so that all PMs sit with their engineering teams. The benefits have been remarkable.

Benefits

• Engineering hears the positives about the product for a change.
• We’re building smarter. We have a faster development cycle AND our product is more aligned with what our customers really want.
• We’re more agile. Engineering can change strategy at a much faster pace.
• Less friction between teams because of firsthand feedback.
• More realistic development time estimates.
• Engineering has developed relationships with customers and proactively runs ideas by them.

I know this strategy may not work for everyone. But it’s time for engineering to have a face with your customers. The days of engineering teams sitting in a dark room with a case of Mountain Dew wearing huge gaming headphones is as old and archaic as I am.

If you’re in PM and are struggling with your engineering team, involve them more and get their feedback early in the process.

If you’re in engineering and don’t understand why you’re building something, push back on your product manager and ask them how what you’re working on will provide value to the customer.

If you’re a customer and you’re getting an update on the roadmap or doing usability testing with a software vendor, make sure both PM and engineering are there.

When PM and engineering work together, the results are powerful. This structure puts BetterCloud in the best position to build amazing products and execute for our customers and partners.