Product Management

The Case of the Serrated Chef’s knife.

We are lucky ducks – our friends gave us their beach house (right on the beach) for a couple of weeks this month.

The kitchen of this dream house- with its fantastic 6 burner viking range – has a random beachhouse assortment of crummy implements to cook with. Among these was an an assortment of cheap knifes, and no good ones. (I do know what I’m getting them for xmas). I cook. So, I pull out I knife from the block on the counter. Its shaped like an 8 inch chef’s knife, but has a serrated blade. I declare it completely useless, and again after I actually try to chop an onion with the thing.

My husband, who does not cook (but does run the grill) says “it has to have a purpose – they wouldn’t have made it otherwise.” But, you, my savvy business friend, have already guessed the problem here I’m sure. Some manufacturer of goods headed for a discount chain said – I know how to stamp metal, I can put a plastic handle on it. I’ve looked at a knife catalog. I see chef knives and serrated knives. I know its harder to make a sharp blade than a serrated one, so I’ll put a serrated edge on it.

The manufacturer didn’t seem to get that chef’s knives are for chopping and serrated are for slicing soft things. And that if you try to do both neither works. The manufacturer surely didn’t ever cook or even bother to ask his wife or maid or chef or whatever.

The analogy here should be pretty clear. If you do not truly understand the purpose and value of your business or product you are very likely creating the equivalent of that serrated chef’s knife. Beware.


The Distant Voice of the Customer

My current project (full time) has been challenging  – its so different from what I’ve done in the past that its taken me a while to get grounded, identify the key challenges and plan of attack. I’m working with enterprise software.

Now this particular software, digital asset management software, is powerful stuff – to the point of the near magical. It – when properly applied – powers creativity, collaboration and distribution of some of the worlds most interesting and valuable rich media.

But its enterprise software, which, I’m coming to understand, means that it must also be somewhat of a chameleon. It gets customized, enhanced, and integrated in nearly every installation. And the customer list reads like a who’s who of several media-intensive industries.

So – as a new leader for this product, there are several huge challenges that make it very different from the consumer software I’ve lived with.

First – the value proposition. Its a rare consumer company that can spit out its value proposition cleanly at any given time. (Course, think of the ones who actually can – google, intuit, ebay – notice anything?).  For a highly customizable giant of enterprise software, well, they certainly don’t have any less of a challenge there.

Second – the voice of the customer. Enterprise products are not sold to an individual, but to a committee, and not to the end users, but to someone who has various motivations, hopefully one of which is to enable those end users to do something, better.

So – the voice of the customer – which I’ve gotten pretty good at seeking out in the consumer world is now in a different place. And I’m trying to chase it down. I’m starting with customer visits – but frequently you meet with the IT folks responsible for implementing the solution – not with the people who feel the need, or the people who will be using it.

The team is all in agreement about the need to find the voice – and is pursuing several ways of getting there (hey – you heard of this web 2.0 thing? its pretty cool, and fortunately, they have).   I’m not sure how the company will feel about it, but I think that the pursuit of this voice is important, and I hope to document how we get closer to it, and how that intimacy changes things.

Web 2.0 and Digital Asset Management

Yesterday, I gave a talk to people developing high end DAM solutions about how Web 2.0 is affecting DAM. In short, Web 2.0 is creating a proliferation of media, changing the process of creation, collaboration and use, and driving the need for DAM solutions to integrate with more tools and think about metadata a bit differently. Moreover, Web 2.0 is changing how major media producers think about new ways to use their assets.

Here are the slides. Web 2.0 and DAM

trouble in the middle of the room

I have this big color laser printer. You know the kind – its about the size of a large old fashioned tv set, and about as heavy. Its sitting in the middle of my office. On the floor. Its been there for over a month. Its in a spot where I actually have to walk around it to answer the phone, or to get on my elliptical trainer, and I makes it difficult to pace the way I prefer when on conference calls.

So why is it still there? Cause I don’t really know what to do with it. I don’t want this giant to take up the space where my current printer is. Its too nice to get rid of. I don’t feel like taking the 15 minutes to hook it up.

This is exactly the kind of thing that happens in most product development cycles. These problems. That everyone knows about, but doesn’t exactly know what to do about.

And there’s the opportunity right there to make the difference between good and great. Find those things littered around the floor. Sometimes they are UI issues. Sometimes its a feature that’s lacking. Or the fact that the customer research says everyone wants green and you have blue. Or the fact that the licensing isn’t (and won’t be) in place. Don’t ignore them. Make it an absolute virtue to say – hey look everyone – theres this stupid printer in the middle of the @*#&^@ floor.

You may catch some heat, at first. In some companies I’ve worked for, the pressure to ignore these things gets greater as you go up the hierarchy (I’ve never been able to understand this, and its one reason I find consulting to suit me). But ultimately, if you can be part of a team, that will never pass a printer in the middle of the floor without deciding what to do about it and then doing it, you will do great things.

5 Product Requirements for Social Media Widgets (at least)

Lately I’ve been asked to help design or add input to several widgets designed to create a sticky and viral presence in places like Facebook, Blogs and other “New Media” outlets.

Here are some rules of thumb that I’ve come up with. As I see it now, there are 5 basic requirements to make these successful. The importance of each will vary according to the goals (don’t neglect to examine yours) and context of the widget.

1. Compelling seed content.
Text, Video, Flash, Game-like interaction, or – heavens – Utility! Whatever, but you need a reason for people to look at it. Some kind of clever, meaningful, interesting or compelling hook. Humor is a good one. The chance to “do good” is another. Entertainment (puzzles, etc), a third. The Bob Dylan Facebook app does this in spades for me, even though its not very useful.

2. Sharing
Every good widget must have some easy way of sharing it or otherwise spreading the word. Otherwise you’re shortsheeting yourself. Super Groups on Yahoo have some great features for this. Check “John Stewart for Moderator“.

3. User contributions

Most new media widgets should have some way of allowing users to contribute – either through comments, or ratings, uploading pics, or something. The easier and more creative the better. But be careful about having people harshly rate people who are trying to do good.

4. Look and feel.

This is New Media. Design is IMPORTANT. It needs to be hot, fresh, and interesting. And it needs to be ergonomic. Think about what links and actions need to be visible and make them boldly so. No boring hotel room art, you know what I mean?

Also – you need to be sensitive to who’s using it and how. Do you really want consumer ratings of people’s earnest thoughts? Frame your language and your functionality so that people feel good about using it, not insulted (well I guess there are some rare funny things where insults work, but who looks at those every day?)

5. Tracking

No good product should go unmeasured. Continual Improvement (aka learning) relies on objective measures.

Number of interactions, number of referrals, and number of productive referrals should all be tracked. Return visits – people who come back to check on it should be counted.

Got more? Please share what you’ve learned in the comments.

Slogging through the details? Get Agile.

So – the strategy is clear, the thinking is exciting, the opportunities immense. What’s left now is to get it done.

And its not all easy, and its not all fun. So how do you slog through the minutia? These details that can be painful to document are so important to success, so – what’s the best way to approach them. In my case, I’m working on a Product Requirements Doc for a client. (I’ll do anything in the name of a great outcome). The outlines of the product are clear and everyone’s excited about the product direction. And still – getting every detail on paper is taking longer than it should, and delivering less value than it should.

The answer here depends on the circumstances, and who you are, and what you’re trying to achieve. But I think the best weapon is a buddy. Have someone to walk through the details with, and instead of a boring, painful, process, you suddenly have a vibrant conversation.

Who’s your buddy? Well – in the case of a Product Requirements Document your best allies are Design and Engineering. They each bring great insight to the table, and its essential to be in lock step with them. This small step is, in fact the first step toward an Agile methodology.

The Agile process is one of the most productive, efficient and altogether engaging team structures. In this process, design, product management and engineering get together, define the general outline of the product, and take a deep dive on a piece of it. Then, engineering goes and builds that piece, and design and product management go deep on the next piece. Then engineering gets involved again, and so it goes. Iterating, learning, iterating and learning. I’m a huge fan of this process, and most engineers I know like it too.

The key tools of the process are collaborative communication, trust and respect. People need to be on their toes and know you are too. The result is usually a highly aligned team, with a high degree of collegiality, and a killer record for getting things accomplished. People work in parallel, but not in isolation. Engineering isn’t left waiting while product management figures stuff out, and product management isn’t left with the huge burden of arranging every detail on a platter for

There are pros and cons to this method. The pros is that it can dramatically reduce schedule risk, gets all the best minds in synch, and can be very responsive to changes in requirements and learning. The cons, is that if you must have extensive face time. If part of your team is half way around the world, it can be extremely difficult to achieve this level of communication. I’ve not managed it yet myself. But, I’m sure that if I could, the productivity of the team would soar, as would morale.

Has anybody out there been successful with Agile across continents?

But Agile is not just for Engineers. Agile tactics are very well used in design, marketing and any other part of the business where cross-functional collaboration is key, and parallelism is important. There are great books on the subject, but I think the best way to learn about the method is to chat with people using it, or even better, attend some sessions. I can hook you up with some, if you like. Just ping me at deb at productfour dot com.

How do you know when you’ve got the right value proposition?

Last month, I wrote a post about the Value of a Value Proposition .

It must be a useful subject, because almost all of my search engine traffic comes to this one post. Again today I found myself talking about the value proposition with a client. Its the most precious thing you have – its what is valuable about your product or company. And it isn’t always easy to formulate or agree on.

Here’s some hints about the process:

– If your value proposition takes two paragraphs to describe, you aren’t done yet.

– If you don’t have any customers or potential customers who say – yes – I have that issue, I need that solution, then you aren’t done yet.

– If you need to rehearse the sentence to get it out of your mouth properly – you aren’t done yet.

If everyone in your company or team, when asked, will spontaneously say something more or less identical – you’re getting darn close.

Now – just because you aren’t done yet, doesn’t mean you don’t have something really special. What it does mean is that you haven’t yet made that connection between whatever brilliant insight you have and your customers world view. So what can you do about this?

1. Talk talk talk talk and then listen, listen, listen, listen.

Tell as many people as will stand still about your idea. You’ll probably go through a phase where you’ll get one of two responses:

– blank faces

– one or two people (who probably like you a lot for whatever reason) will tell you that you are a genius.

This is not a good phase. And I’ve spent some quality time here. The best thing to do here is to try to get those blank faced people to talk more. And, of course those people who think you’re a genius too – but its more important to be able to explain it to the blank faces. Ask them (if they haven’t turned away yet) to help you by explaining back to you what they think you might be saying. And listen. Don’t dismiss – even if you think they have no vision. They may have no vision – but neither will 99.9% of your future customers and investors. You really do need to be able to explain it.

Another technique – draw a chart. Make a picture of what you think you’re offering. Now make a completely different chart to describe the same thing. In other words try to look at the problem in lots of different ways, get creative about seeing it from other people’s perspectives. Try a usage table – a tool I use quite a bit – one column is a list of possible users, the second column is the value they’ll get out of the product, the third are the features that support this. Once you’ve nailed your value proposition, this is also a nice tool for the development of your Product Requirements.

Focus groups. If you have the ability, try a focus group. I’ve seen the value proposition fall out of the most unlikely mouths while standing behind a one way mirror, after we’d worked on it for months. A different, objective perspective can be very illuminating.

Online surveys. Once you think you’ve got it. Consider it an hypothesis. Use an online survey to test your hypothesis. Online surveys are cheap and easy. The hard work is in formulating the right questions, developing your email list (not all that hard, if you know your audience) and most importantly, listening to the results – especially if they are not what you predicted.

Once you have the right value proposition, it will feel right. It will be easy to describe. People will nod their heads. Survey results will start making sense. The product, design, marketing, positioning, everything will begin to fall in place, and all thats left is to execute flawlessly.

Good news – I think my client’s got it. Its short, its sweet, he and the team can repeat it easily, and people get it. Yipee! Now to that flawless execution….

So, Now that I’ve found the trouble…

I recently posted about the trouble seeking process (The Virtues of Looking for Trouble). So, I’ve been asked the question – what do you do with trouble when you find it. Well, in short, the goal is to minimize risk, and maximize opportunity.

How. Well – first, as I said before, its imperative that you alwas have your ears open for trouble, and make it a regular activity to discuss it with the team, and management (get them used to it – it will pay off in the long run!)

1. Keep blame out of it.

Even if someone really screwed up, there’s time to deal with that later. Blame will not help solve the problem, and blame will make it much, much, much harder to discuss problems productively. No one will bring up bad news if they fear they’re going to get slammed. Most of the time, assuming that you have a good team, the blame will be that we work fast, blazing paths through the unknown – we’re paid to innovate – that means we just don’t always know in advance how things will play out. So – respect and trust. (And if you do have a bad egg – deal with that quietly, and make sure its about skills, talent, match, etc and not about “this went wrong and its your fault”. But that’s a different subject)

So back to dealing.

2. How bad is it?

Is there general agreement that if this problem is not managed, the launch, the schedule, the user adoption, the business model or other critical success metric is in clear peril? If so, all due attention should be These should be at the top of the agenda, and made as visible within the organization as possible to get to the best possible solution.

3. Verify and characterize the problem.

Once the problem is on the table – get general input on it, then make it someone’s responsibility to map out the size and shape of the problem. Is it a lack of information? Is it a technology glitch? A new competitor? A design flaw? A resource issue? What are the ramifications? Best, worst case scenarios? Is there a critical decision point, or is this something we can just watch.

5. Identify key decision factors: (ie if this outside event does not occur by this date, then we’ll… ), if this metric hits this mark, then…, if this study returns this result, then….. If the blah blah group (or partner, or whatever) can’t deliver x, by y, then…

4. Decide on a course of action: Solve, remediate or watch.

Some problems can’t be solved, but you can keep them from making fools of you just by tracking them, and responding when and how you can – is it positioning, PR, expectations setting on the schedule, feature-rejuggering, getting new partners, etc. A team that can sit down and really hash out problems will get to the “aha” moments much faster. A team that is looking for, and dealing with trouble effectively is going to make it to the goal line faster, and score bigger.

Moreover, many problems, found and managed early, will make your project, product or campaign much much better than you might imagined. Stay tuned for “How canceling a project won over our users”.

The Value of a Value Proposition

My current project is working with a very early stage startup. They, like all new startups, are working very hard to get what they want and need – a great product, excited users, some press coverage, and investors.

We’ve been discussing how to best define, refine and articulate their unique value proposition, and some very interesting (to me at least) themes emerged from the conversation. While there is considerable and unique value they are building, they, like almost every product team, are struggling a little to find the best way to articulate it. And, not being traditional product managers, they asked a simple and great question: Do we really need a value proposition?

Some team members went on to say things like “After all, the bar is so low to trying free online products, all there needs to be is the slightest hint that it could be useful. And besides, we can’t possibly predict all the values the product will have for all its users”.

At first, all I could think was “oh, brother.” My next thoughts went down two roads. The first was a list of the reasons you do need a well articulated value proposition (is it just a sacred cow?). I’ll share these down the page a bit.

But the other thought train went this way: we are in a phase where the power of emergent behavior (the wisdom of crowds) is newly important and useful online. One of the key values that this team is actually expressing, is that in addition to creating specific new value, they are enabling their users to find and create the value they want, and to use the product as a platform to get done what they want to get done. They are designing this product to allow its users to influence its value and its future.

That is terrifically cool, current and powerful.

Having said that, there are still some pretty good reasons for articulating your value proposition, even if part of your value proposition is dynamic.

A value proposition defines and describes WHAT a thing does and for WHOM.

So – why is this useful.

1. A value proposition helps design the product.

Once you are clear on what your product does, and for whom, your choice of features, navigation, look and feel are much easier, because you have clear criteria to evaluate your choices. (Anybody ever work on a product that did everything for everyone? Was it fun?)

2. A value proposition helps market the product.

A value proposition is not the same thing as a tag line, but its certainly the first step. More over, the what and for whom identifies your target market. (obviously articulating the value proposition is not necessarily the first or only place you’ll be discussing the target market, but it helps reinforce the very deep relationship between the target and the product). Knowing your target is, of course, the first and most important step in finding, targeting, messaging recruiting and building relationships with those people.

3. It helps investors/management/partners get excited.

Hard to get excited about/support/invest in a product where only a couple of passionate guys “get” it.

4. It doesn’t matter how low the barrier is to trying your product, you still need folks to be motivated enough to click, or blink, or inhale or whatever minor action they must take to try it. And, once they’ve tried it, they need to find it useful (or at least highly entertaining). If your users aren’t clear on the value proposition, then they have to “discover” it for themselves. That means they need to think and/or work, and there go those barriers again, shooting upward.

A clear value proposition helps you communicate to the engineers, designers, to investors, advertisers, and most importantly your users. It makes every decision easier because it encapsulates your ultimate goal. Providing something valuable for somebody. Even if the value is that users can participate in creating the value.

We don’t always have the chance to recognize, let alone challenge our fundamental assumptions. I really enjoyed this chance to think about this one.