ProductMarketing.com

MySpace’s death spiral: insiders say it’s due to bets on Los Angeles and Microsoft — Scobleizer

I’ve been asking people involved what went wrong and two common themes have evolved:

1. Their bet on Microsoft technology doomed them for a variety of reasons.
2. Their bet on Los Angeles accentuated the problems with betting on Microsoft.

via scobleizer.com

Nice assessment by Scoble, who believes that talent location and technology debt are the root causes of MySpace's failure. What decisions have you made that are limiting your opportunities for growth.

One "persona" that many product managers miss in their planning is "the system." Sometimes we have to do things to improve the health of the architecture or make it easier to build on. It drives sales people and execs crazy because features for "the system" don't demo... but, like a healthy work-out at the gym, you do it because it's good for you in the long-term.

Don’t Solve Half of the Problem

Nice post by Scott Sehlhorst at Tyner Blain on splitting user stories:

User stories were created as lower-overhead use cases that served to better describe chunks of valuable software that could be rapidly developed, delivered, reviewed, used, and improved. Writing user stories that undermine that intent – rapid, valuable, incremental delivery – is a bad way to write user stories.

Source http://tynerblain.com/blog/2010/09/08/sprint-backlog-splitting-user-stories/

In particular, good user stories are about the persona, not the product. Or as Scott puts it: "The right approach is to first solve all of the problem for a subset of the users."

Alas, many of the "roles" definitions we see are not personas but vague titles. "As a provider of IT support..."?? Man! That isn't specific! What kind of IT support? Linux, Mac, Windows, mobile? What kind of organization is supported? Large business, mom-and-pop shop, family, everyone who has met a member of my family?

Agile is supposed to help you make better products faster. Focus on personas and their problems and a lot of the rest falls into place.

Posted via email from Steve Johnson on product management

Video Thursday: Adam Sadowsky OK GO video

Adam Sadowsky engineers a viral music video - Adam Sadowsky (2010)

Listen for the requirements of the video. Actually, they're not requirements; they're themes. What if your roadmap was more about themes and less about features?

Posted via email from Steve Johnson on product management

Make it easy to switch

We've all had the problem: a desire to change products but a fear of the disruption. Why haven't you switched from wired phones to VOIP? Why aren't you on BaseCamp for projects and Google apps for email? Why are you still using <old_thing> instead of <new_thing>?

Answer: it's less the fear of change than the hassle of change. What we have now is working; the new thing requires learning the new way and figuring out how to move existing assets (files, data, configuration, workflows) to the new platform.

Change is never easy but vendors could do a lot to make it easier. If your strategy involves getting competitors' customers to switch, what are you doing in development and marketing to help them switch? 

Apple has had this problem for years. Some people want to switch to Macintosh but, golly, all my files are on a PC. Does Mac have Word? How hard is it to understand the file system? Is the Mac compatible with <whatever> at work? That's why Apple offers the "Why you'll love a Mac" which assures you that it's easy to switch from Windows.

I love Posterous. This new (to me) service is simple; just email it to blog it. While some services require you to mess around with HTML, with Posterous, just email your post and forget it. Instead of a silly email address, it knows anything from your email address must be for your posterous blog. Nice! Oh, and then it autoposts to other blogs and social media. Super easy. 

"But wait"--you say--"I already have a blog and all this great content on <something_else>!" No problem, go to http://posterous.com/switch/ and they'll move all your data too. Still not sure? Check http://switchto.posterous.com/ for success stories and see what other have to say about it. Oh, and what a great marketing message: Switch your site to the simplest publishing platform on the planet.

Many of our development plans focus on adding new functionality to win new deals, or upgrading functionality to help existing customers. But what about your competitor's customers? How can we help them? Do you want them to drop what they've been doing and switch to you? If "yes," make it a development and marketing priority. Make "Switch" a development and marketing theme for an entire release or series of releases. Develop tools to move their data, workflows, scripts, configurations. And create marketing programs to explain how easy you've made it to switch.

Now... how do I switch the house over to Ooma?

Posted via email from Steve Johnson on product management

How do you prioritize?

mobilecrunch.com reports:

We just got word from Aliph that their $99 Jawbone Icon headset will be gaining support for the A2DP (music streaming) protocol tomorrow, by way of a free update made available through their AppStore-esque headset customization portal, MyTalk

A2DP is the #1 request in the Jawbone discussion boards... as shown here, 8 pages of discussion, the busiest thread. 

So... hat's off to Aliph for listening to their customers.

Are you listening to your market? Market evidence is the key to building a backlog that is prioritized for the market, rather than being a list representing opinions and politics. 

If you need help in bringing the market's voice into your product management, we're delivering the Practical Product Management and Requirements That Work seminars in Tampa on May 15-17. Come learn the best practices for how market evidence drives product decisions. 

Posted via email from Steve Johnson on product management

ICON and distribution strategy

In the past, discussions about distribution strategy always focused on channel. That is, how to get the product from the factory through the channel to the customer. But nowadays distribution means that we need to explore also the best way to deliver, maintain, and use the product.

Should we sell direct, through multi-tier, via the web, over the phone? And how should we deliver? Hosted, SaaS, on-premise? How will we deliver patches and upgrades? Nowadays the choices seem limitless.

Virginia recently passed a law forbidding use of handheld devices while driving.  (That's called an Opportunity in SWOT analysis) I do have a bluetooth capability in my Toyota but the hands-free lacks noise canceling and it just doesn't satisfy. I find myself shouting into the phone and am exhausted after a short phone call. So, as a result, I was in the market for a new bluetooth headset. 

What next?  I could go to Amazon and do some comparisons. I could also go to the vendors' web sites and see what they have to say. I could go to the phone store and see what they have. Three different ways to buy. After looking at a few different sites and blogs, I decided on the Jawbone ICON from Aliph. 

http://us.jawbone.com/productsPageIcon.aspx

Now I have to think about delivery. If I buy from the phone store, I can see the product and take it home immediately--but alas, my store only carries The Thinker (black on black, a safe choice) With Amazon, I can choose from two different models but I'll have to wait a couple of days. With the vendor site, I can choose from all six models but have to wait a week or more. In my case (and maybe yours), I'll do anything to stay away from a retail store and Amazon didn't have the model I wanted so I was stuck with the vendor site. Sigh, hard to wait a week (a week!) when you're used to next-day service from Amazon. 

Here's where it gets really interesting. You can change the usage over the web. Plug the headset into a USB port, go to the web site, and the website shows you how you can configure the headset. You can choose among six voices ("You have two hours of talk time remaining") and three or four applications including voice dial and memo capabilities. Logically, they could someday download a firmware update, add A2DP capability (please!) or offer other features. 

So the distribution questions you ask yourself on a new product introduction is not just what channel any more but what is the best way to deliver, maintain, and use the product. I find it annoying lately when products don't automatically update themselves with bug fixes and new features. Operating systems have done it for years; virus programs do it too. 

The more you understand your buyer and user personas, the more you'll know how to answer distribution questions. 

Have you thought about distribution in these terms? 

Posted via email from Steve Johnson on product management

Your enhancement process

Here's how your customers think you process their enhancement ideas. 

I used to do a simple presentation for customers (and sales people) that illustrated how ideas turn into features. Carl Knibbs suggests this process: 

See Carl's post at http://www.carlknibbs.net/blog/2010/2/10/how-we-build-the-product.html

Customers want to know that you have a process for planning and prioritization. Most customers don't really mind being told "no"-- they mind being ignored. So the next time you have a group of customers onsite, think about a simple presentation (and maybe it's a single slide) that shows your planning process. Maybe you should show them your prioritization system and get their feedback. For more on prioritization, see http://pragmaticmarketing.typepad.com/productmarketing/2010/02/setting_prioritites.html

Posted via email from Steve Johnson on product management

Setting prioritites grounded in the market

If you've ever had to review a long list of requirements, you'll appreciate this. I was recently asked:

I wonder if you have insights on good feature/function/backlog prioritization – especially when there are a ton of them (700+).  Specifically, best practices for how to store and retrieve the important ideas, while being able to ignore the ones that will never matter.  Some think we need to store any and all ideas so that we don’t forget them, but the noise is overwhelming and the organization of the content is impossible.

A fast way is to rate all 700 with +1 or -1. Give it a +1 if it'll help many of our customers; a -1 if it'll hurt some of our customers. You can use a 0 for neither good nor bad. Then set aside all those with a -1 and  just look at the +1 items.

Now rate them using a five point scale. I use:
5     Evaluators: Minimum purchase criteria
4     Potentials: Lose time or money due to problem
3     Customers: Difficult to achieve primary goal
2     Customers: Difficult to achieve non-primary goal
1     Other: Not in target market segment

or you might use:
50: solving the problem will make money for customers
40: solving the problem will save money for customers
30: they think it will make/save money
20: an existing customer wants the problem solved
10: a cool feature idea

Ideally, I'd like to have some assessment of how many customers are affected. You can count the number of requests or you can survey a set of customers. I've also been impressed with the choice model approach found at www.uservoice.com

You'll find it's easier to get valid ratings when you're talking about problems than features. People always seem to want more features, even the dumb ones. But asking "do you have this problem" seems to get better results. And yes, you want to write down all the problems and feature ideas, even the dumb ones. (After all, how many of those dumb ones came from your executive team?)

The most important thing is to figure some way to include the market in your decision making. Employee voting is rarely a good idea.

We discuss prioritization methods in our popular Requirements That Work seminar. More details at www.pragmaticmarketing.com/seminars

Setting prioritites grounded in the market

A common sight in agile shops is the product owner shuffling his user stories.

"This before that. Oh this is a good one. Ooh, move that one to later."

It sure seems that many people use a prioritization scheme based in opinion, deal-of-the-day, and "whoever I talked to last."

In Requirements That Work we recommend a prioritizing formula grounded in market problems: how many people experience it and how bad is it?

In a recent session, Adrian shared this scale representing the impact of the problem on customers:

50: solving the problem will make money for customers
40: solving the problem will save money for customers
30: they think it will make/save money
20: an existing customer wants the problem solved
10: a cool feature idea

The challenge of prioritizing is that we have more ideas than we have resources. Don't you? So we must learn to prioritize.

And what did we learn from Star Trek II: The Wrath of Khan?

"The needs of the many outweigh the needs of the few… or the one."

When prioritizing, choose a scheme that is simple and objective, which aligns the product strategy with the market and its problems. Try to use a formula to represent the product strategy so that your team makes changes to the formula and doesn't just move around individual items.

What is the impact of the problem on the persona? Let's get that right.

What scale do you use?

Setting priorities...

...is a challenge. If everything is "must have", how can you choose?

http://geekandpoke.typepad.com/geekandpoke/2010/01/priorities.html

Posted via email from Steve Johnson on product management

Product Management in Pictures (cont'd)

Saeed with http://onproductmanagement.net does it again.

Product Management In Pictures - Feature Requests From Sales

View more presentations from Saeed Khan.

And if you didn't see the first one, go to http://onproductmanagement.net/2010/01/08/diagramming-product-management-1-requirements-and-reality/

Posted via email from Steve Johnson on product management

Requirements and Reality

Saeed at http://onproductmanagement.net offers this clever presentation comparing our desired state and reality.

Diagramming Product Management #1 - Requirements and Reality

View more presentations from Saeed Khan.

It wouldn't be funny if it wasn't so true.

Keep 'em comin', Saeed.

Posted via email from Steve Johnson on product management

Let's play "Req or Spec": insert a page break

There's often confusion about what is a requirement and what is a specification. Let's play "Req or Spec." Is this a requirements or a specification?

 

Which is this? How would you improve it? Add your comment below.

See On Reqs and Specs for more.

Let's play "Req or Spec": login verification

There's often confusion about what is a requirement and what is a specification. Let's play "Req or Spec." Is this a requirements or a specification?

Which is this? How would you improve it? Add your comment below.

See On Reqs and Specs for more.

Let's play "Req or Spec": initiate diagnostic routines

There's often confusion about what is a requirement and what is a specification. Let's play "Req or Spec." Is this a requirements or a specification?

Which is this? How would you improve it? Add your comment below.

See On Reqs and Specs for more.

Let's play "Req or Spec": import text files

There's often confusion about what is a requirement and what is a specification. Let's play "Req or Spec." Is this a requirements or a specification?

Which is this? How would you improve it? Add your comment below.

See On Reqs and Specs for more.

Let's play "Req or Spec": duplicate images

There's often confusion about what is a requirement and what is a specification. Let's play "Req or Spec." Is this a requirements or a specification?

Which is this? Add your comment below.

See On Reqs and Specs for more.

Concise Requirements | Tyner Blain

Scott Sehlhorst at Tyner Blain makes a simple but powerful point.

 

You want your requirements document to read like the lines, not the points.

Read more in Concise Requirements | Tyner Blain.

It's always about the problem

In our training classes, we emphasize the importance of solving market problems. Describing problems encountered by our target personas. It's the problem that drives product requirements. Yet we've become an industry of feature-speakers. "I want this and this and this and this!" Wait! What is the problem??

My friend Luke Hohmann wrote about this in his post "Market problems are still THE problem — even when you’re Agile!"

As teams embrace agile methods, some seem to have jumped backwards a decade, getting back to the thinking that opinions drive feature decisions; this is just wrong. Use market facts to uncover problems that customers are willing to pay to solve. Perhaps it's the pace of agile development, needing new items for the backlog every other week. Or perhaps it's a shift in the power of the "team" over the power of market facts.

If you're a product manager, you need to be delivering quantified market data to your product team; if you're a developer, you should demand it. Otherwise, the team will use their opinions of what they think people want. After all, in the absence of market facts, he who owns the compiler wins.

Requirements - Discover, not Gather!

My friend and colleague Stacey shared this with me. She writes,

Over the years, I have found that I always have an internal screech when someone uses the term “requirements gathering”. The term itself makes it seem like the requirements are lying there, and the Product Manager just has to grab them and pop ‘em in a document. If we were creating custom solutions, the phrase might be more accurate – all of the users would be identifiable, and we could truly gather requirements from them. We’d still need to design the product in ways the user couldn’t even imagine, but with a limited and fully identified group of users the job would be pretty straight-forward

The requirements beast changes its face when we’re building commercial solutions. We define a market segment, to help narrow the field of potential users. Then, we have to find potentials in that market segment, and watch them in their environment. We need to interview them, to really get to know their situations. And, we need to find ways to sample the segment at large, to find out how pervasive problems really are across the segment

Each potential we visit may use slightly different ways of expressing their problems. The adjacent systems may vary from one location to another. Some problems only occur in parts of the market segment, and the problems sometimes seem to vary greatly

Product Managers must study all of this information, and somehow discern which problems are most important. We have to narrow our field of vision from “all possible requirements” down to sets of problems that, when solved, will incent people to spend money. Only then can we actually document the requirement (Every [frequency], [persona] has [problem].) and clearly guide our teams to build a product that’s worth our time and energy

To build awesome commercial solutions that people want to buy, we can’t just GATHER requirements – we have to study the market, and analyze their problems. Requirements aren’t gathered, they are DISCOVERED through our analysis of market evidence. Then, they are written with the right context to improve communication to our teams, helping our teams build outstanding solutions that resonate in the market

What do you call the process of discovering requirements?