There’s an old anecdote about a chicken and a pig.
It goes like this:
A pig and a chicken are walking down the road.
The chicken says: "Hey Pig, I was thinking we should open a restaurant!"
Pig replies: "Hmmm, maybe. What would we call it?"
The chicken responds: "How about 'Ham-n-Eggs'?"
The pig thinks for a moment and says: "No thanks. I'd be committed, but you'd only be involved."
It’s a funny story, but it shines a light on an issue that, when it comes to building products, can mean the difference between success and failure.
Project management vs. product ownership
The technology industry is putting tremendous stress on older, more established businesses.
There’s a lot of pressure to become a “tech” company — fast, responsive, and agile — and to build great products (which, after all, “are the future of this company”), but most of these teams don’t really know how.
Teams often have project and task managers who work within siloed departments like IT and Design, but in many cases, no one owns the whole product and there’s no one leader to unify their teams.
And that’s a big, big problem.
The negative impact of traditional project management
Here’s why this approach is dangerous: when siloed departments are each given responsibility for a narrow slice of the end product, they’re incentivized to finish their tasks, not to create the best possible outcome for the overall product.
But good products can’t be built by a fractured team who are simply checking the boxes across the board.
Individual department “wants” must take a backseat to the product’s needs, or you won’t end up solving the right problems.
For example, let’s say that the design team is given an initial brief and a deadline. But midway through the first phase, the development team encounters an obstacle that will require a difficult trade-off; either critical design elements get changed, or the entire project gets delayed while a new technical solution is engineered.
These are the tough decisions that product teams face constantly, but in a task-based project management environment, each siloed team will be fighting for what’s best for them; in this case, the design team won’t want to go back and re-do their work...and if the project gets delayed, well, "that’s on the developers".
If everyone working on a product doesn’t have accountability for the end goal (a successful product that achieves the desired outcomes), then the team will always have immense trouble making those tough decisions.
Like the chicken, everyone is involved, but no one is fully committed.
Product management: A better approach
In a world full of chickens, the pig is king.
The “pig,” as we’ve defined it, is the product owner — a single person accountable for a successful outcome and in charge of guiding the product through development and release into your market.
The product owner is empowered to make decisions about the product.
She makes tradeoffs, ensuring the product meets the needs of your users.
She says, “Our users have clearly stated that they need these three features. Build them.”
But she also says, “We don’t need those other three features you proposed. Don’t waste time working on them.”
And then she says, “We need to change course on this design. Let’s make it happen.”
In that way, the product owner guides the product to its final outcome — a successful release that achieves its targeted goal.
This is a role that most businesses simply don’t have. In fact, the “product owner” role is typically given to a department manager — and whose interests do you think they’ll fight for?
What a Product Team looks like
If you want to establish a product management approach, you’ll need to reorganize so the team reports to a single product owner, rather than a department manager. The “product owner” role will likely need to be created.
You’ll need more pigs than chickens to make it work, which might be difficult if there are already many layers of management in your organization.
But the pain of reorganization will let you create and release much better products to market, much faster than you could with your old project management approach. No handoffs. No “throwing it over the fence.”
Instead, you’ll have a unified team with a single goal—the successful release of the product — rather than departments working together on an ad-hoc basis.
KPIs will be focused on business value and value to the user, rather than on department productivity stats. And the entire team will understand what “success” really looks like, and they’ll rally behind those goals.
How to implement the product management approach
My best advice is to start small.
- Pick a group of people who are willing and able to shake up the status quo in your organization.
- You must have at least one person senior enough to push back against the inertia of other departments still using the project management approach.
- Give this team more responsibility and hold them accountable for clearly defined KPIs.
- Start with the smallest scope you can deliver that provides value to your users. That way you’ll be able to point to the success of the experiment.
- Avoid using existing tools and processes that were created for a different purpose.
- As much as you can, make your new product team unique. Let them choose their own tools and processes. And then support their decisions.
Bringing pigs into the chicken coop
Switching from a project management style of working to a product management style of working is a big change. It’s a whole new way to measure success and to pursue it.
It will feel risky — because it’s more than just checking boxes.
You’ll also face resistance from the chickens. Many employees are comfortable simply doing what they’re told, rather than contributing to the design and definition of a product.
But the change will be worth it.
Conclusion
More than once, our team has been called on to rescue a project that’s gone off the rails for the reasons in this post.
A company might have missed several deadlines with a new product. Or after months (or years) they finally released a new product — only to discover their users didn’t find it helpful or couldn’t figure out how to use it.
They need to fix their product — and fast.
In nearly every case, we found a situation where many were involved, but no single person had ownership of the result.
If your organization has struggled to release products on time or failed to achieve product/market fit, then I suggest you start with ownership.