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.