Does product management slow down your company?
Facebook’s success — and mistakes — are based on its developer-driven culture, not because Zuckerberg is some evil mastermind.
What Causes Your Business to Be Slow?
Paul Young put out the call for the third annual You Might Be A Product Manager… list. If you are spending your holiday wondering if Jason Calacanis is right, and product management is actually preventing your company from being successful, you might be a product manager.
Facebook’s success — and mistakes — are based on its developer-driven culture, not because Zuckerberg is some evil mastermind.
The Zuckerberg Doctrine: Developers design products with significantly improved speed and functionality compared to product managers and designers, outweighing potential mistakes and drawbacks.
Sound like link bait? Maybe, but you’re probably a product manager :). Jason’s put his money where his mouth is – he changed the way things are done at Mahalo (his human-curated search / answers company).
In under 30 days, we completely overhauled our product-development process, removing everything between the developer and iterating on the product.
We eliminated positions and process. We made it clear the developers were to make the decisions even if those decisions resulted in a developer being 50 percent slower because they were busy *thinking* about the product (as opposed to just transcribing features from the product manager wireframes).
As you read through the details of the analysis in Mr. Calacanis’ newsletter, you’ll see that his position is not ultimately as generalized as the above quotes appear to be – Mr. Calacanis (who I’ve seen, and to whom I’ve listened for several years, but never met) is talking specifically about startups. However, he uses AOL, Yahoo, MySpace and Google as his “bad” examples – not exactly startups.
I think this logical flaw may be leading Mr. Calacanis to demonize the wrong bad actors.
 |
| ProductCamp Austin 6 |
Implicit Product Decisions
When I was still writing software and leading teams that were writing software, I would occasionally point out that all software is designed – even if someone sits down and just starts typing code. There is, at the minimum, implicit design happening in the mind of the programmer. It might not be “good” design, but there is always design. There is always a method to the madness, just not always a considered method. The same is true of product management.
- The creation of every feature and capability, in every product, is preceded by the notion that having this capability is a good idea. That’s what product managers do – decide which capabilities a product should have.
- Eliminating product managers does not eliminate product management.
If “developer led” companies are still doing product management, how then, are they moving faster? Mr. Calacanis addresses valid points – his “bad examples” do seem to move pretty slowly, and his “good examples” do seem to move faster. So what’s really different? John and Roger and I will be framing the discussion at ProductCamp around how to move faster, and not throw the baby out with the bathwater.
I might describe what Mahalo has apparently done as follows:
- Mahalo, with product managers involved in product decisions, was not moving as fast as Mr. Calacanis desired. So they reorganized so that product managers were no longer involved in the process – in hopes of having a faster process. Mr. Calacanis indicated that in a trade-off between “better” and “faster,” he would prefer “faster.”
Agility
The core of the agile development philosophy is – “fail fast. learn. improve.”
All of the other stuff in the implementations of agile comes back to this – consider the main ideas in the agile manifesto*
- People over process: empowerment to fail and learn and improve.
- Value working software: learning is experiential, and you can’t fail or improve without shipping.
- Collaboration: You have to understand someone else’s problem before you can solve it. Too many products emerge from insular and isolated “exploration.”
- Encourage, don’t inhibit change: If you punish failure you prevent learning. If you prevent that new knowledge from being applied, you make learning irrelevant.
*Agreed – those aren’t the words used in the manifesto. Same ideas, though.
When you talk about business agility, while the mechanics might be different, the goals are the same. Fail fast. Learn. Improve.
Mr. Calacanis, in my interpretation, is saying that this is exactly what he wants the Mahalo team to do. I applaud that goal.
Does he have to “kill all the product managers” in order to infuse his company with (business) agility?
Is product management the antithesis of agility? By definition, product management is still happening – just without product managers. Maybe the product management process has room for improvement…
Market Driven
As a good product manager, you are market driven. What does that mean to agility?
- Fail Fast. Maybe you’re making decisions that delay launches until you know “the right product.” That would hurt agility.
- Lean. Are you listening to your customers, and learning from them? Great!
- Improve. Does what you’ve learned lead to trying something different, with a hypothesis that it will be better this time?
OK, so being market driven will help your company learn and improve. That’s the up-side. It may also enable (but not cause) some corporate dysfunction. If your organization punishes failure, or is afraid of mis-steps, and you’re market driven, you have already heard this conversation – don’t (schedule | design | release) until we get [feedback X] or [insight Y].
A tight coupling with your market is a powerful tool. It can be used for good (learning) or evil (avoid failure).
Whew. Good to know that being market driven is not the source of the problem. An organization that is afraid of failure is the problem.
Mahalo’s experiment may work – Mr. Calacanis clearly intends to encourage the “fail fast” element. So, when his developers are doing product management, they will have an opportunity to succeed by being market driven.
Bureaucracy
In fairness, Mr. Calacanis is really only prescribing the “no product managers” approach for startups. Startups are not particularly bureaucratic. Perhaps Mahalo was becoming bureaucratic. It is easy to see the big companies mentioned in the newsletter as being rife with bureaucracy. Even if you could fail fast, learn, and improve in a world of t-crossing and sign-offs, your definition of “fast” would not match your competitors.
Piloting your company would be like flying a Cessna twin-prop airplane in a world of super-sonic Gulfstream jets.
How are product managers introducing overhead into your product creation process? What parts of product management are “not worth the delays?”
There are very real “slow things down” activities in the product creation process.
- Some activities can be removed.
- Some activities can be improved.
- Most activities can be done in parallel with the product creation process, eliminating delays.
What Have You Seen?
There are a lot of stories from the trenches out there – what are you seeing? Have you tackled this already? How did you make it better.
I hope that our session focuses on helping attendees, in a very real way, make their product creation process more effective, and make their businesses more agile.
Reference: Product Management Slowing You Down? from our JCG partner Scott Sehlhorst at the Business Analysis | Product Management | Software Requirements blog.
