Does product management slow down your company?
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
If you’re planning to attend ProductCamp Austin 6 – January 15th, 2011 (register here if you haven’t already), then consider attending a session that John Milburn, Roger Cauvin, and I are going to host – discussing this topic. If you can’t attend, then jump into the conversation here. John and Roger and I have been talking about this and exchanging some ideas since the newsletter came out – and we really know how much better ideas get when we open the conversation up to the community. We’re looking forward to doing that at product camp, and I’m writing this to open it up now – so please, chime in!
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.
Of course, we don’t have to wait until January 15th – we can start talking about it right now…
The PM process is designed to bring the outside world in to make sure you design, develop and deliver products that delight people. I don’t really care if you have PMs who do that work, just as long as it gets done. The problem is most developers want to code what they want to code, not what the market needs. Agile just makes it easier to figure out when they are wrong faster.
Hey Bob, thanks for chiming in!
I completely agree that the right goals for product management are to bring an outside-in perspective to designing products. The “design for your customers” idea is definitely the right one, in my opinion. I’ve definitely worked with people who “code what they want to code” and may have even been one of those people in my dark past. :)
Also completely agree that iteration (as a process approach) gives you the ability to turn out “something” faster. It also gives you the opportunity to get feedback faster and make changes. That doesn’t mean that you will (1) go get the feedback or (2) respond to it – just that the opportunity is there.
I agree with the problem that Mr. Calacanis identified, that the process takes too long. So, how do we make the process faster, without decoupling market-inputs from our decision making? Or is that just impossible?
Wow. Where to begin…First o all, user experience team should do wireframes, not product managers. And developer-led team by definition ficus on what technology cando, leaving out the input of real people doing real stuff. To find that out, you need UX professionals leading agile, collaborative design. Keeping in mind that UX is NOT “making it look purty,” we should ensure that developers focus on capability, PMs focus on viability, and UXers focus on desirability. That way we accurately balance tech, business, and experience.
Hey Joe – welcome to Tyner Blain!
I smiled when I read your comment. I spent about 9 months of this year embedded with a UX team, so I had forgotten that a lot of companies still think about “making it look purty.” I do completely agree that people who are trained in ethnographic research, usability, information architecture and visual and interaction design are much more likely to create a better experience for users than people who aren’t trained.
I think the “We have to figure stuff out in advance” versus “We can’t know in advance what is really needed” debate is an interesting one, mainly because there’s truth in both sides of the debate.
I also think that true innovation happens in the intersection of “what needs to be done?” and “what can we do with this?” It is both the discovery of interesting problems to solve and novels way to solve them.
I really like how you pointed out that design is both an agile and collaborative process. I’ve had success when the experience design process (how it works, looks, feels) moves in parallel with the software design process (what it does, how it does what it does). Making the process of deciding ‘what should it do?’ happen in parallel is how I approach compressing the cycle without undermining it – that introduces the “don’t shop a bad product” problem too.
I like how you’ve concisely framed it as viability, capability and desirability too – I have to think about that some more.
Fun debate, and thanks for joining in!
As a former product manager at a decidedly NON-startup company (Motorola) for a decidedly NON-consumer product (automated fingerprint identification systems), my experience is certainly different from Calacanis’. One advantage of a streamlined approach, however, is extremely streamlined communication – when a single person functions as both the product manager and the development manager, then product decisions can be communicated by talking to yourself.
The drawback, of course, is that one person either ends up doing everything, or (more likely) not doing everything. Do all Mahalo developers attend every trade show to survey customer reactions? I doubt it. How much time do developers spend logging on to a support site and directly answering unfiltered questions? Not much, I suspect.
As was noted above, Calacanis has not eliminated processes; he has just instituted some undocumented processes, perhaps along the lines of “Code will be checked in by Friday at midnight.”
Perhaps in drawing the comparisons with organizations such as Google, Calacanis believes that this current organization and process structure can continue to be used at Mahalo for 10 or 20 years or more. However, I strongly suspect that Calacanis will reverse himself sooner rather than later, and post a newsletter item that boldly states the virtues of letting coders code, unencumbered by all that stupid stuff that dumb companies do by forcing coders to “analyze the market” and “shape the product direction.”
Hey John, thanks for the great comments and welcome to Tyner Blain!
Pragmatic Marketing has a neat phrase that they used (and maybe still use) in their training – when encouraging product managers to not do other people’s work (like code reviews, or wireframes, or giving demos). “If you do someone else’s job, who will do yours?”
I think that same thought can be reviewed in the opposite direction – the work of product management happens, so if there’s no product manager, who does it? And what is that person no longer doing?
I do think the problems that Mr. Calacanis identifies are very real ones. When I think about the costs of decisions and operations, I think in terms of three things – money, time, and risk.
For companies that emphasize continued support of legacy products and customers, and companies in highly regulated environments; risk tends to be the 800-lb. gorilla. Risk of non-compliance with regulations (and the associated audits and penalties), or risk of “breaking” customer operations or damaging relationships with those customers.
For companies that are in start-up mode, and companies with fast-moving competitors; time (or business agility) tends to be the dominant factor. When most of your prospective customers haven’t picked a solution yet, and when your current customers are at risk of moving to someone else (low barriers to entry, lack of satisfaction with your products & services, etc), you have to be able to win them over. That’s one of the reasons I like SaaS models – because they very visibly bias you towards improving the services you provide to existing customers, versus a myopic focus on new customers that is combined with ignoring current customers. When you’re competing with someone else who is redefining your market, while you stagnate, you will lose current customers and / or fail to acquire new ones.
If you’ve got a good business model, the costs in money (of developing your solutions) are an order of magnitude lower than the value of sales to new (and recurring) customers. There’s a tipping point where cash-flow in exceeds cash-flow out, when you’re still small. That’s why having enough “runway” (enough cash to cover costs until you become cash-flow positive) is important for start-ups. Mr. Calacanis has talked about that quite a bit (I’ve been listening to and learning from what he says for several years now – even saw him at SxSW last year). When you’re trying to hit it out of the park, in a “go big or go home” way, the costs of developing your solutions are a lot less than the costs of marketing your solutions – you “buy” awareness, and if you’re solving the right problems and have a compelling message, you’re gaining customers. I think Mr. Calacanis alluded to this too in his previous reference to “slow product” companies – companies that fund growth organically (from cash-flow) versus an investment.
I would expect, for Mahalo, that the big cost is time. There is a lot of advertising revenue available to Mahalo and their competitors. There’s almost no friction for customers/users to switch from one answers / search solution to another. Getting something “better” out there quickly is key to keeping people around (out of loyalty / satisfaction), and getting people to suggest Mahalo to other people.
Do you fire a lot of shots, hoping that one of them hits; or do you fire fewer shots, each of which is more likely to hit? If the delay between shots from “excessive aiming” introduces too much cost, start shooting more frequently – knowing that each shot is aimed less precisely, but perhaps well enough. That actually sounds like the right thing to do.
The question is, when you eliminate product managers (from the product management process, which I argue still exists implicitly), are you snapping the sights off your gun, and eliminating your ability to aim? Is Mahalo’s business a sufficiently target-rich environment that little or no aiming is required? Is your (everyone, not just you, John) business one that still requires some forethought? Probably. Are you, as a company, moving as quickly as you can? Probably not.
Until a lot of “mistakes” are launched, you won’t feel the pain of releasing “bad” products. That’s on the other side of the pendulum swing. I’ll be surprised if Mahalo’s market and Mahalo’s position in it are fundamentally the same in 10 years, in such a way that the same strategy makes sense for them 10 years from now. But I’m willing to be surprised too :).
Thanks again, loving the insights that you and others are infusing into this discussion!
I commented on Jason’s comments here http://launch.is/blog/2010/12/14/launch002-what-i-learned-from-zuckerbergs-mistakes.html#comment-119551121.
I’m probably biased but of course Product Management is needed. And one of the companies he points out as being developer driven, Google, seems to think so as well.
Awesome, and thanks, Haig!
Of course, now I’ve got a lot more people sharing great ideas, that I need to read. :)
Wish there were a way to mash-up/consolidate/colate the conversations that happen across the different properties.
Scott
OK, so that’s awesome! Thanks, Mr. Calacanis!
So, comment-threading doesn’t work with trackbacks (tweets) :). Mr. Calacanis tweeted a link to this article, which is what I was referring to.
It looks like Facebook employs Product Managers (https://www.facebook.com/careers/department.php?dept=product-management&req=131473549833) but Jason decided to fire theirs based on these revelations.
Coming from an agile background, I agree that empowering developers makes for better products. However, the product manager in me can’t help but be skeptical of giving all of the decision making power to he who holds the compiler. In the case of a Facebook style application, the developers are also in the user base of the product. I’m curious how Calacanis’s strategy would work when that is not true.
I work in at a non-start up where the users of our products are pretty much the opposite of your architypical developer. Our devs have trouble designing for our user base (instead of thinking about how they would want things to work if they were the user).
Hey Chris, thanks for the great response!
Question for you: What is it that a product manager does (but developer does not) that makes the product worse? Or the other way around – what does a developer do (sans product manager) that makes the product better?
I think your “implicit understanding of the user” point is a good one, generally. Not sure I buy it for facebook – I don’t think it is an application designed “by developers, for developers.” MS Visual Studio is :)
Very good points all around. With the need for shorter development cycles I suspect more companies may find themselves using this logic to cut out product management, but – as you say – product management can never really be removed. It would then get done by developers, sort of.
But for every company that is of this mindset – that product management isn’t needed – I can only presume there are decision makers who have had experiences in their professional career where they felt product management was too slow or didn’t add value. Under what other circumstance would they reach this decision, if not because they’ve seen product management slow things down or if they had no understanding at all of the role product management plays in driving value (and revenue).
In other words, it’s up to product managers to show that we can work as fast and drive as much, if not more, value as the development team – faster even. And to do that we need Agile principles that will help us fail faster; we need the tools to make quick informed decisions and an organized workflow that gets stuff done fast.
We also need our tools to deliver product execution transparency and visibility to all parts of the organization. That way developers know why they are developing something and executives understand the dynamic linkage between corporate strategy and product execution and can see progress.
We had an “innovation jam†at Accept Corporation a while back – went through dozens of feature ideas and created several of them in a weekend. That’s the kind of speed we need, but too many organizations are in an endless cycle of collecting data in order to get higher levels of certainty so they feel they’re making the right choices. That is just not sustainable.
-Christine Crandell, Accept Corporation
Great comments, Christine, and welcome to Tyner Blain!
I think you make really good points – the action of removing product managers from the product creation process (versus not adding them in the first place) has to be a reaction to something.
The first one, to your point, is best addressed in my experience with agile principles. I love your phrase “quick informed decisions” – that’s the crux of it, and the source of the catch-22. You have to be quick (easy, just shoot from the hip), but you have to be informed – without delaying progress to become informed.
What has worked really well for me is incremental investment in evergreen artifacts that live outside of the project scope. Mary Gerush, at Forrester, has a good report Exploit the Real Requirements Lifecycle that addresses this. I was fortunate enough to be interviewed by Mary and even quoted (I’m famous!).
The key idea is that your understanding of your market is an intellectual property asset, not an encapsulated component of a particular product, project, roadmap, or release. I’ll be doing a webinar in March with the folks at Ryma on this topic, and will announce it here when details are finalized.
The second point, I think, is 90% about being “good” at product management, and 10% about being good at managing your career interpersonally within your company. It may be that you’re doing great stuff and folks don’t realize it. More likely (Occam’s razor), you’re not doing a good job – either your insights aren’t valuable, your communication is ineffective, or your strategic conclusions / direction are undermining themselves.
The third point is an acknowledgement of the reality of corporate politics. I work with large companies and startups (and have worked as an employee of both too). Folks who say that startups don’t have politics are at best wearing blinders, and more likely, sticking their heads in the sand. The politics is still there, just manifested differently.
As a product manager, you have to lead (often without “ordained authority” or organizational “management” reporting structures). Leading does sometimes involve confrontation, and always involves helping an organization move in a direction it wouldn’t have otherwise.
If you aren’t changing the direction, you’re not a leader – you’re just walking in front of everyone else.
You have to remember that everyone was already heading “in the other direction” before for a reason. That reason may be because some other leader in your company wanted it that way. A bad approach to getting the company to change directions can be a CLM (career limiting move), if you fail to work effectively with other leaders.
Thanks again!
Scott,
Great post. I love it when someone tries to argue that a key function/skill is not necessary in web/software development (whether it’s PM, UI, or QA). As you rightly pointed out, PM is an activity, not a person or a job, and will happen implicitly if it’s not done deliberately. Same for UI design. Personally, I think it’s best to have a highly skilled PM responsible for doing PM for your team (and a skilled UI designer for UI design) instead of nobody or an untrained person.
The reality is that designing and building world-class product “takes a village” of skills. Collaboration across multiple people is not easy, requiring good skills in communication, design articulation, teamwork, and group decision-making. I think a lack of strong collaboration is the core reason that leads many companies to complain about “things being slow”.
Having to reach a joint decision with one or two other people is hard for some teams. Having discussions and collaborating takes time and effort. Trying to convince a teammate that your recommendation is the way to go can be challenging. People who are ineffective at convincing others often stop trying and instead start relying on political reasons why they don’t need to gain agreement. At that point, eliminating the other party may make that annoyance go away, but it’s not solving the fundamental issue.
To be fair, there can be situations where there are “too many cooks in the kitchen” and there is decision paralysis because so many parties have to be on board. Clear roles and decision making processes can help mitigate that.
I’ve given several talks on product management at the Web 2.0 Expo and other conferences. You can see my slides at http://www.slideshare.net/dan_o/presentations
Thanks again for the great post!
Dan Olsen
CEO & Cofounder, YourVersion
http://yourversion.com
Great comments, as always, Dan! And thanks for the link to your presentations. I particularly like http://www.slideshare.net/dan_o/product-management-101-for-startups . I think that presentation will particularly help founders appreciate the value of staffing a product manager to handle that product-strategy stuff, so they can focus on all the other elements of creating a company.
Your emphasis on “convincing people” is spot on too – that’s a key element of leadership without “authority” (and with authority, for that matter). One of the reasons I like talking with Jim Holland and Michael Hopkins so much is that they both emphasize the leadership elements of product management.
Thanks again!