In Defense of Personas

defenseAlan Klement has been on a recent war against personas. I enjoy his posts, but after reading his most recent, felt the need to step up in defense of personas.

Alan’s primary beef with personas is that “they are made up and not real”. Because of this, he claims that they will ultimately cause teams to make erroneous decisions in the design in development of features. Instead of using user stories with personas, Alan proposes writing “job stories” that omit the persona and focus purely on situation, motivation, and expected outcome. I have no beef with the elements of his job stories (not sure I see the need for a new name), but I do take issue with omitting personas – and I’ll tell you why….

Persona’s provide valuable context. Without this context, we are left in the dark as to important aspects of the user such as their technical acumen, domain knowledge, frequency of system use, etc. Each of these drives very important concerns when designing for a new feature. Consider the following example:

My user wants to input a new order into our system. If I were to write one of Alan’s Job Stories for this, I might say: “when I need an order placed, I want to enter that order into the system so that it is promptly and accurately fulfilled.” No persona, but I know what needs to be done, why, and the desired outcome. Alan would have us believe this is a good story. It’s not. In fact, it sucks. It sucks because we know absolutely nothing about our user. Would you implement this feature differently if the user was the end customer vs. our employee in a call center? Of course you would. What if it’s an employee who handles orders for us and 50 other companies, so is not all that familiar with our products? Again, hell yes, it gets implemented much differently.

I think the problem here may be that Alan has never seen a good persona. Personas are not made up. A persona is, by definition, an archetype user. This means that we do real research with real customers to create personas from shared relevant attributes of these real customers. We don’t make up attributes and we don’t generalize. The only “made up” aspects of personas are the little bits of color we give them to help them to develop a personality, e.g. name, favorite band, kind of pet, car they drive – but it’s critical that these fictionalized attributes of our personas not be relevant to our product set. E.g. we don’t make up their favorite band if we are on the Spotify team. The relevant attributes then are quite real – and extremely important as we are saying they are shared across a significant number of our user base. These then serve to inform our designs. So going back to my example, if I create a persona John like this:

John has worked in our Dallas call center for 12 years. He can tell you the part number of nearly every product we’ve sold in that time as well as the available sizes and colors. He works five days a week, eight hours a day takes approximately 800 orders in any given work week. During peak hours (9A-12P) he is 98% utilized, meaning of these 180 minutes, he is on the phone with a customer for 176. Calls with customers can range from 1-15 minutes and John is motivated to keep calls short during peak hours….

I won’t go on, but are you starting to think about some of the requirements implied by this persona? How much do we miss out on if we don’t know these things? If I add to this persona that John drives a 1976 Gremlin, listens to Black Sabbath, and frequently participates in Civil War battle reenactments… this is kitsch – everyone knows not to take it into account when developing our order entry system.

Don’t give up on Personas. If you aren’t finding them useful, it’s likely you aren’t doing them correctly. Spend some time getting them right and they will serve you well.


Product Management and Customer Service

Because they are often close to the customer and have the ability to effect the roadmap, Product Managers in (in B2B companies) often get pulled in to customer support issues. Having seen this quite a few times, I’m feeling the need to write down my thoughts on Product’s role, with regard to Service Level Agreements (SLAs).

So here it is. When it comes to SLAs, Product is responsible for:
1) Defining what the market requirement is with regard to service levels (market expectations)
2) Working with MarComm to effectively present SLAs to the market, including packaging/branding as appropriate.

Product’s role is not:
1) To deliver on the SLAs (Service Delivery)
2) To track performance vs. the SLAs (Service Delivery)
3) To review performance with the client (Sales / Acct Mgmt)

Re: #3 above, this probably varies with company size. In a large company, it makes sense for product to be involved with such account reviews, but not to lead them. In a start-up, I think it’s a very good idea to have the product guy act as the account manager for early and “best” customers.


Efficacy is a Function of Intent

This is a lesson I learned at the dojo, for which I see broad application.
If you don’t have complete intent, ruthless focus on your objective, you will not succeed.

Punch with the intent to hit, otherwise you will never hit.

If you aren’t ruthlessly focused on success in your career, quit – do something else.

If you don’t wholly believe in your product – find another.

Applications for marketing? For one, pursue a solid segmentation strategy. If you are a small company and are late to the game, you aren’t going to win in the general market – you do not have complete intent. Sharpen your segmentation strategy, focus on the markets where you can win and pursue that strategy ruthlessly.


Samsung & Apple – A Lesson in Competitive Research

Competitive research is a critical part of a product manager’s job. There’s a right way to do it and a wrong way to do it. The Apple v. Samsung case has done a great job of illustrating both.

Let’s say you find yourself, as Samsung did, suddenly well behind a competitor in some important aspect of your product. Customers are telling you this, analysts are telling you this, your kids are telling you this. You have an obligation to understand the problem and to articulate it in nauseating detail to your development team. It’s your job to not only close the gap, but to leap ahead of your competitors. Time for some serious competitive analysis. Samsung did the work here – check out this exhibit from the trial.

The Good: Samsung did a very detailed analysis of the gaps between their product and the iPhone. You need to get to this level of analysis in order to understand the problem.

The Bad: They went beyond analysis and actually used screen shots from the competitive product to describe what needed to be done in their products. Presumably this was given to developers. They are basically saying “make ours looks just like theirs”. Yea, that’s illegal.

Image from Techcrunch

Image from Techcrunch

If the next version of your product comes out and looks and feels exactly like the competitive product that you used to perform your analysis, you have made a serious mistake. The Samsung product manager should have thrown a flag at this point. Going to market with a straight-up rip-off of your competitors product is not only extremely uncool, but as Samsung just learned, illegal and expensive.


Product Management’s Role in Product Design

There is some interesting banter on Twitter between @crankypm and @rcauvin concerning the role of product management in product design. Design is a topic near & dear to my heart, so my thoughts on the subject could not be contained by Twitter’s 140 character limit.

The point of contention in the debate is whether Product Mangers should be using tools like Balsamiq (of which I am also a big fan) to produce mock-ups. Cranky and Roger have gone back and forth on this and I think they are talking past one another. I’m guessing that they actually share a great deal of common ground on the subject, so am going to do my best Mother Teresa and attempt to demonstrate that common ground here.

Roger’s spot-on that too many companies don’t appreciate the value that an interaction designer can provide, and as stated in his Feb ’08 blog post that critical role is all too often filled with someone with the best of intentions, but the wrong skill set.

Cranky, too, is correct in her assertion that there’s nothing wrong with a Product Manager picking-up a design tool in order to communicate a product concept with a mock-up – a picture being worth a thousand words and all that.

It seems to me that the critical issue here is the intent of the mock-up. I use mock-ups frequently myself, because I am a visual person and so communicate more easily and effectively with a picture than a wordy document (never know if from this blog would you). I know that I’m not an interaction designer and don’t want anyone mistaking my attempt to communicate a concept as an attempt to specify a design. So, I am very careful to include the following disclaimer on every mock-up I produce: “…the UI is intentionally low-fidelity and serves only as a narrative – this is not a UI design artifact”. I also call my mock-ups storyboards and accompany them with a little textual narrative as this helps to drive-home the point.

The open-ended discussion that mock-ups stimulate are critical in the very early stages of product design. Just as important, however, is the need for professional interaction design; there are few things more important to a successful software product than nailing the user experience and an interaction designer is key to achieving that goal.

I hope I’ve helped to move the conversation forward, because it’s an important one.


Scrum as a Product Requirement

I’ve been asked more than once if it is within Product Management’s purview to prescribe a product development or project management methodology.gears Experience has taught me that Scrum works, and I believe that it is within my authority to prescribe a process through which I believe success to be possible, and perhaps more importantly to veto a process that I know to be doomed for failure.

I was recently asked to make this case in writing and was pleasantly surprised at the results. I feel like I’ve stated the case for Scrum – or something quite close – with legitimate business reasons. Following is an excerpt from a product charter document on the subject of project management:

This project will be executed under a somewhat unique set of circumstances. Selection of a project management process that supports these circumstances is critical to the success of the project. It is the responsibility of The Team (Executive, Product, and Development) to select a project management process that will be used for the lifetime of the project. Following is a discussion of the circumstances of the project along with indications for the project management process.

This project is not being fulfilled for a single customer. We are building to where we believe the market will be in one year’s time – our perception of where exactly that is will very likely change over the next 12 months. For this reason we must follow a project management process that allows for continuous adaptation of the project deliverables.

The company has a rather small team of highly qualified and experienced software developers who have worked together for many years. Such a team will not be helped by a heavyweight process, but more likely hindered by it; clearly this is not desirable. Therefore a second requirement on the project management process is that it be “lightweight”. In other words the artifacts of the process must be few and straightforward, requiring minimal documentation and creating little process overhead.

Accountability for product strategy lies with the SVP Product & Strategy. In practice, however, the responsibility for defining product strategy is shared across multiple organizational disciplines including Executive, Development, and Sales. An additional requirement on the project management process then, is that it must provide transparency to in-flight development in order to facilitate shared responsibility for product strategy.

Finally, we anticipate a great deal of interest in this project from existing customers, prospects, board members, prospective investors, and press. To maintain credibility, we cannot afford to have discrepancies between reports on project status. We must speak to all external stakeholders with a single accurate voice. A final requirement on the project management process is that it must allow for measurement of progress towards goals and milestones.

I’m curious how the selection of methodology/process is decided at your shop. Does PM prescribe it, do they even have a voice? Also curious what you think of my argument above.


Considerations for New Product Development

photo by gfpeck
Carl Knibbs on his aptly named “carl’s product management blog” has a post discussing considerations for getting the green light on development of a new product. I agree on all Carl’s points and would add:

How Big?
Market/opportunity size will typically be the number one concern for a new venture. A new product should make it the same. Find a way to quantify the opportunity and present it in a way that makes sense to someone not familiar with the market.

Why Us?
Carl covered “why me” – I’d like to see some statement that explains why your company is poised to succeed at this new venture.

Whatever the reason, spell it out. Why is your company uniquely positioned to succeed in this endeavor?

Who Else?
Who else is likely to attack the opportunity. While the opportunity size defines the size of the pie, the answer to this question helps to define the size of your slice (given the answer to “why us” above). Under most circumstances, a small slice of a small pie is not an interesting proposition regardless of the answers to the other questions.

Why Now?
If you’ve ever been involved with a start-up, you know just how important timing can be. Some might say that it is the most important consideration – though it’s nearly impossible to predict “perfect” timing”. It’s important to explain why this is the right time to solve the problem for your target market. What makes today an important time for the market?

Then What?
Like any good start-up, a new product should have an exit strategy. What’s the long-term vision. Do you integrate with other parts of your portfolio? Does this establish the beginning of a new portfolio? Does the product get spun-off as a new business or acquired by a competitor. This isn’t a “burn the ships at the shore” statement of strategy, but it’s important to have some idea of the potential outcomes as they will drive long-term strategy.

Nice list Carl, thanks for carrying the conversation forward.


Cheffing-Up a New Product

image by martin borjessonCharlie O’Donnell‘s post on “Why Product Management is More Like Baking than Cooking” has some great points. In the post Charlie is lamenting the fact that when it comes to product management, the leadership of startup companies seem to want to wing-it (like a cook) as opposed to execute on a proven process (like a baker).

Having more than a little cooking experience, quite a bit of product management experience, and much less baking experience; I’d rephrase the title to say that being a product manager is more like being a Sous Chef than being an Executive Chef. If you haven’t worked in the F&B industry before the difference may escape you – follow me here, I think it’s worth the effort.

Executive Chefs provide vision. They start with a general direction, an idea of the dish they want to serve and a knowledge of the ingredients on-hand. They turn themselves over to the creative process, relying heavily on past experience and gut feel, and voila! they turn-out a plate. The success or failure of the effort will depend upon the skill of the chef, the quality of ingredients, and also rely a good bit on fortune. Many a chef has ruined a dish while learning something that later helps him to prepare a real gem of a meal. This is the software equivalent to R&D.

Sous Chefs, on the other hand, are professional managers. Their primary job is to productize a creation dreamed-up by the Executive Chef. While the Executive Chef has only to create the one dish, one time, and take as much time as she requires to finish it; the Sous Chef must crank out that dish a hundred times a night, with limited resources, while maintaining consistent quality. To be successful it’s got to be more science than art at this stage.

Which brings me back to the point of Charlie’s post. When you are cooking with someone else’s money, it’s time to hire a Sous Chef. Someone who can bring transparency, predictability, and repeatability to the process of taking new products to market.

Note that this does not mean, as some of the comments to Charlie’s post have implied, that the creative process ends when a professional Product Manager takes the reins. Nor does it mean that you are now following a waterfall process where the product goes into the oven and you are stuck with what comes out. As Charlie rightly points out, measurement tools are a critical component to the long-term success of the product. Going back to the analogy, the Sous Chef will monitor key performance metrics such as the amount of time it takes to prepare and serve a dish, what the temperature of the dish is when it leaves the kitchen, the number of dishes ordered per restaurant guest, and overall guest satisfaction. By monitoring these important indicators, the chef can course correct if things start to go awry. The same is obviously true for the product manager.

If your product is ready to leave the test kitchen and get out into the real world, take a big step towards repeatable, predictable success and hire an experienced, professional Product Manager.


Effectively Communicating Product Requirements

up_graphI was just looking at a video of Lizzie O’Leary (Bloomberg) on discussing how to effectively tell a story with numbers. What an important skill for product managers. As the leader of your product it’s not only critical that you have data to back-up your decisions regarding product futures, but that you can effectively tell a story with that data.

If you are a product manager, you’ve likely internalized the tenets embodied by Steve Johnson‘s quote, “your opinion, while interesting, is irrelevant.” The best product managers say “no” to every new feature request and to keep saying “no” until the case for the feature is made. The case for the feature is made by data. But the product manager’s job is not done when the feature is added to the backlog and prioritized. It’s important to communicate the need to stakeholders inside and outside the organization. Use data; turn it in to a story; indicate the trend and the opportunity. Explain to all stakeholders why you want to do something – not just what you want to do.


Before You Say Yes…

the "ACK" factorDavid Radzialowski and Joshua Steffan of B2B Product Makers have posted a great piece titled “So You Got the Product Manager Position – Should you take it?” It got me reflecting on the same question, so I’ve added some to their excellent list of issues to consider before you say “yes”.

Budget. David & Joshua mention this, but I want to call more attention to the subject. As a new PM you will want to travel. Well, you may not want to, but you’ll need to. You need to hit the road with the sales team, listen to existing customers and prospects, attend trade shows, and get a feel for the market. Depending on the product you may want to visit production or service delivery locations. You’ll often have the need to purchase tools. You may need to fill in gaps by outsourcing important functions like win/loss analysis if no one is doing it today. All of these activities are critical to your success and you’re being set-up for failure if you aren’t going to be able to get the necessary budget.

Product Development. This may seem like a silly question to ask, but it’s an important one. Does the company make their own products or do they resell? Your job as PM for a VAR will be about portfolio management, service delivery, and partner relations. Is this your thing? If it’s not, then you’ll want to get with a company that is developing their own products.

Innovation. David & Joshua talk about idea generation, but I’d like to focus on a slightly different aspect – is the company committed to innovation? Lots of companies aren’t and it’s not a requirement for financial success. But it might be a requirement for your happiness. If it’s important to you – ask the question.

People vs. Process. This could be a sub-header under “culture”. Does executive management put its faith in people or process? It’s not a fair question, as the answer is likely both, but where is the emphasis. If you are a Six Sigma-type, you might be fine with an organization that believes in process over people. If you are the highly creative, color-outside-the-lines-type, maybe not so much. Fortunately salary is a pretty good indicator of the value a company places on talent. If they are paying below market they probably don’t feel like they need the cream of the crop to be successful.