Product Management: You Get What You Pay For

Another excellent post from Scott Sehlhorst, this time pointing out that, even without product managers, product management still happens. Scott’s post is a response to Jason Calcanis, the founder of Mahalo, who wrote the following:

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).

If Calcanis is arguing that his company doesn’t need product managers, because they just are in the way, Scott makes the obvious counterargument:

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...Eliminating product managers does not eliminate product management.

Actually, I don’t think Scott goes far enough. Let's take Calcanis’ claim at face value. Mahalo is an example of how to build a product without all those pesky product managers and their wireframes. If so, then Mahalo is proof positive that you need PMs to save you from building a very bad application.

What does a Mahalo say?
I’m not a big fan of Mahalo, for oh so many reasons. Since the point of this post isn’t to beat up on Mahalo, I’ll focus briefly on just one that’s relevant for our discussion: Mahalo’s ability to express clearly its value to a potential user, and the path through the application to realize its value. 

If you’d never heard of Mahalo before, the site itself gives little sense of what you’re supposed to be doing there. (If you don't believe me, show it to a complete Mahalo novice and see what happens.) Apparently, there are a lot of trendy topics being discussed there, from Justin Bieber to Apple, but it’s not clear what sort of valuable information Mahalo provides that’s distinct from, say, a Bieber fan site, or the Apple support forums.

Let’s say that we’re trying to lose weight, something on the mind of a lot of people in January. Type “lose weight” into the search window, and you get a page summarizing a few tips for the aspiring dieter. (Tragically, there are also candy coupons available from the Featured Mahalo Topics section in the right column.) There’s also a long comment from moondriver52, who may or may not be a diet and fitness expert, so it’s up to you to decide the value of what this person is saying. (That user’s profile page provides nary a clue.)

If you search for innovation, you get this page. Here, I might start to get the idea that Mahalo is a place where people can pose questions, but it’s a mystery how all the pieces on this page fit together. What does M$5.37 mean? If that’s a tip, who’s doing the tipping, and why? Are the top members experts in innovation, or just people who are very active on the site? And why would I buy Mahalo dollars? 

(And yes, I know, there is a help page, available through a tiny link at the bottom of the page. That almost makes my point, all by itself.)

La-la-la, you’re not telling me anything useful, la-la-la
Mahalo’s usability issues are probably the result of both (1) lack of understanding of how the site looks to novices, and (2) lack of feedback to point out this problem, if it’s not immediately aware to the Mahalo developer. In both cases, information is missing from a decision-making process that led to a bad design. In both cases, the role of product management is not to slow down that decision-making process but to accelerate it. To put no fine point on it, PM is not doing its job if it doesn’t provide the information needed to accelerate decisions.

Of course, the development team isn’t doing its job if it isn’t making the time to absorb this information. Basically, developers at Mahalo, or anywhere else, get what they pay for. No PM, no information. Make it unclear what you really want (if not wireframes, what then?), and you have a weak foundation to complain about what you get.

To put a face on this process, let’s take the kind of information that puts a face on the user, personas. A well-designed persona tells you what someone may do with the technology you provide. It tells you how that person understands and adopts technology, and therefore what’s needed to reach that person. It tells you a lot, in a very simple profile, how to prioritize and design technology.

But exactly when does this information contribute? After all, developers are impatient to move ahead with their work, so timing is everything for any information PM provides. In the most impatient of all development processes, Agile, it’s anyone’s guess where the information might contribute. To the right you'll see a fairly standard picture of, in Scrum, what happens during a sprint. Keep in mind that people are making decisions at every step.

Personas potentially contribute to every point of decision. Since it is not an overly discrete piece of information (such as, “What is acceptable performance for the system, with 500 concurrent users?”), the information is potentially applicable in a variety of contexts. It may take a moment or two to figure out how to plug that information into a particular decision, but it’s preferable to blasting forward with no guidance at all.

Looking at the typical sprint again, it’s easy to see where a persona can contribute. For example, teams can waste a lot of precious time on the most basic step, prioritizing backlogs. If you know that you’re building mobile support for a salesperson who travels a lot, you know how to prioritize individual mobile features to fit that person’s needs and work habits. (Offline support, for example, might be a lot more important than anyone realizes, if you’re designing mobile features for vanilla users.)

Personas can do more than just inform. In many teams, they create a new kind of decision rule. The question, “What does Jane Doe, attorney at law, really need to manage her caseload?” is a natural way of making decisions quickly, based on a shared measure of value.

As I said, this scheme depends on PMs who can deliver useful information and development teams that are ready to consume it. I’m inherently suspicious of anyone who applies the Cartesian method for deciding how to build technology for people unlike themselves. Only the gods have the prescience to avoid, in the absence of information, long arguments over what might be correct, or the extra work needed to correct mistakes made in an informational vacuum.


Product development without

Product development without product managers is like crossing the street without stopping to look both ways: if it works, it's inarguably the fastest way to reach the goal. Other times, though ...

Can you do product management

Can you do product management without product managers? Sure. The better question is why would you want to? It seems that you would be eliminating the one role that is truly responsible for looking outside for information. Failure to do so often results in sites/apps that have no relevance to solving the problems the market you are trying to reach has expressed...and, more importantly, is willing to pay to have solved.

Exactly, Jennifer...

The conceit is...

Anyone can do PM.
Everyone has the time to do PM on the side.
Doing PM badly has no serious consequences.

...All of which are profoundly wrong.

Fantastic post, and I will be

Fantastic post, and I will be forwarding this.

I think I will add on to the comment from Jennifer and Tom's reply.

The conceit is there, and as having been a party to "bad PM" by design, by stacking the deck of PM's with unqualified engineers, it can get quite bad indeed.

I spent 20 minutes trying to figure out what Mahalo was about. Being a former chef, I centered into their section on how to buy knives. Superficial, and not very helpful. A simple Google search unearthed a page of better advice.

Quality assuranse is totaly missing from our post

Quality Assurance is totally missing from your post and probably from Mahalo's team
Usability issues are best detected by good QA .
Split the Product management role between developers and QA( or even Customer relations team) and there will be good balance

Thanks, and "succeed fast"

Thanks for the shout-out, Tom!

I love that you took a religious debate and made it useful with great guidance on how to keep personas front and center during product-creation decision making.

We had a great discussion on this topic at ProductCamp Austin (missed you this time - you should come to the next one) last weekend. We agreed that hyperbole aside, this stuff all happens on a continuum.

We even had an interesting discussion point - is "faster" actually better? @phastflyer snapped a photo of a diagram on the point - - that faster (without getting "worse") is better than slower. We all pretty much agreed that "faster vs. better" was a false dichotomy (I forget if @rcauvin or @ptyoung first said that - but it is definitely true).

"Fail fast" is a valid mantra, and helps organizations overcome the fear of becoming agile. "Succeed fast" is an even better goal, imo.

Thanks again!

Wonderful post to acquaint

Wonderful post to acquaint with actual importance of product management in this competitive world .Study of product management definitely provides me planning or forecasting or marketing of a product in a a particular organization who have that much ability and also included all product related work like product management, product development,product designing etc.development product