Business-driven Product Management

Hi-tech companies grow … they get a healthy, active customer base that loves to contribute. The requests for improvements flow in and the attitude for the first few years is “whatever the customers want” and “whatever to make the sale”. At some point in this growth, the challenge becomes satisfying existing customers, expanding into new markets or deeper into existing markets and innovating the product.

So, what’s the problem? In order to make all fronts happy, you need to balance all three – or least understand that you consciously need to examine all three to determine their relative importance to your company. With a finite set of development, qa, and documentation resources, that in all but the rarest cases, can not do everything, this becomes a real challenge.

Here are the potential results of not addressing this challenge.

• Customer dis-satisfaction – unhappy customers question whether they should renew their maintenance and support contract – jeopardizing a revenue stream that accounts for 18% to 28% of the initial license sale or, in the case of a SaaS model, the actual contract may be in jeopardy.
• Inability to expand markets – expanding into new markets or expanding within current markets means  more potential new name accounts – failing here means not getting the revenue.
• Unable to innovate at the technology level – products that have been around for a few years, need updating to leverage an updated infra-structure or need improvements to make that next big innovative leap in the market – lagging behind invites new competitors to jump in.

Each of these generate innovative ideas (features) or they expose gaps in the product that need to be filled. Business-driven product management is about deciding what to include in the product to best meet balancing the investment in Customer Satisfaction, Market Expansion and Technology Innovation.

A weighted set of business objectives reflects the goals of the business for the near, medium and/or far terms. In other words, it determines the priority of your investment. Are you going to invest more in making customers happy (or happier)? Or is investing in expanding into another market more important. Assessing the feature requests against these objectives will determine the relative importance of these requests and thus your product releases will match your corporate goals. There’s no point in investing in features that do not move you closer to your objectives!

Product Management for Start-ups

Hi-tech start-ups are primarily driven by technology enthusiasts – someone or some group has an idea and away they go. Their focus is on the technology – building on their collective vision. Their tendency is to add to their vision as they encounter potential customers – building the product and expanding their target market as they go. Unlike companies beyond this stage, start-ups do not have the luxury of leaning on a customer base for information to drive the direction of the product. Unfortunately by using this ad-hoc way of managing their product, start-ups ingrain these habits into their everyday processes. As they grow up and suddenly have to juggle customers as well as expanding into markets, these habits become a serious limitation to being able to operate at their best.

But despite the lack of a customer base, start-ups need product management. Product management is about determining what’s important to build; who you are building the product for and when to roll out the capabilities. Start-ups have limited resources so in order to gain the biggest bang for their development dollars, they need to understand what to build first, then second, third, and so on.

Product management is a collection of many activities – from strategic to tactical and from business to technical – the breadth of which can be overwhelming. But there are 3 key activities that are critical to setting the right product management tone in the start-up company.

• Differentiation - identify and articulate how you are different than any alternative your target market has. Maybe you have a direct competitor, maybe you don’t – the point is that your potential customers will compare you to alternatives (including the status quo). Your differentiation needs to be based on your core competency, but must be articulated from the perspective of your target market. How uniquely do you solve the markets problems better than any alternative?
• Market Problems – identify and articulate the market problems that your product addresses. These need to be from the perspective of your potential customers – not from the features in your product. When you are in front of a prospect, they will resonate with the problems your product can solve – not with the features you have. Once you’ve identified and articulated the problems, prioritize them. This will focus your scarce development resources on building the most important features and capabilities first.
• Value Chain Mapping – your product will touch a number of different people or entities as it is deployed and used. You need to identify the value every single person or groups of people or entity will receive from your product. In some cases it may simply be monetary – in other cases it may be usage oriented. If your product does not provide visible, measurable value to everyone in the chain, then someone (group or entity) will not be a supporter of your product – potentially blocking the sale.

And lastly – validate, validate, validate. As a start-up this is tough. Maybe you have a few people in your industry that you can call on – so long as they are respresentative of your target market. Maybe you have some past experience. Maybe you are lucky enough to have a small sample of customers – word of warning, a small sample can skew your findings, so be aware. The point is to get out to as many people that are in or a have a vested interested in your target market to get feedback. To paint the best picture for your audience have a prototype to show the key concepts and a presentation to describe the entire offering.

Conveying Requirements to Development

Quick survey, show of hands … How many reading this post use email? 1, 2, 3, 10, 100 – ok everyone! Question #2 … How many use email for sending documents? 1, 2, 3, 10, 100 – ok everyone! How often have we seen email used as a means of sending a document over the wall – far too often. I’m sure you are thinking the same thing. Your email goes bing; you read it and think where did this come from. Email is supposed to be a communication tool; but it sometimes just doesn’t work.

What happens when product managers send their requirements document over the wall to the development team? In some cases, the designer interprets the document properly and the resulting design document properly reflects those requirements. However, in more cases than we’d like to admit to, the design does not even come close to aligning with the requirements. What happened? The product manager wrote everything correctly, but the designer didn’t interpret it the way the product manager intended. Something was lost in the translation.

The goal of a requirements document is to convey what the feature or capability must do. When things go awry, it’s most likely caused by misinterpretations. In other words, the product manager and the designer (or developer or analyst) need to be on the same page. The product manager must convey his thoughts and knowledge to the designer. In many cases a document attached to an email does not do this.

Here’s what I suggest …

1. After you understand what the key requirements are and who the key users are, arrange a meeting with the development group to present your findings. Don’t wait until you have everything and certainly don’t wait until everything is written down.
2. Put together a 30 minute presentation (10 slides or so) that contains: your vision of the feature, what problems it solves,  and who it solves them for; the typical scenarios in which this feature will be used; and the top 5 functional requirements (expressed as use-case summaries) and top 5 non-functional requirements (expressed as declarative statements).
3. During the presentation ask the audience to parrot back what you just presented, but in their language. This is the most critical part. They have to understand what your intentions are right from the get-go – it will set the tone for the design efforts that will begin as soon as everyone heads to their desks.
4. After the meeting send your presentation to the development team and set a follow-up meeting to review additional requirements and the initial design. This is where the iteration process starts. Don’t wait for everything to be completed … iterate your way to completion. While you are waiting for the next meeting, write your requirements document based on the contents of the presentation.
5. During the days leading up to the next meeting, walk over or phone the development lead to see where they are at. Make sure that they are moving down the right path; listen for hints that they are not following one of the key requirements or have made assumptions about what you presented (remember that people only retain 10% to 25% of what they hear during presentations).

Try it … I think it will help you to ensure that your development team truly understands what you want them to build. And please, don’t throw the document over the wall.

Re-focus the feature debates!

How often as Product Managers do we get into a heated debate over whether Feature A (the cool, sexy one) or Feature B (the mega-reported annoyance) should be included in the next release? Far too often we are in the middle of these heated, opinionated discussions – resources are limited, time is limited so the debate rages on. Invariably the person with the strongest will or voice wins or the biggest, most important customer wins or both.

We always have to remember that product features are like a marriage … until death do us part! In other words, once the feature is in the product you have to support it forever – somebody will always use it; somebody will always want a new and improved version. And to make matters worse, it is an incredibly messy process to get rid of it. The only features that should make it into a release are those that positively impact the company’s objectives – increase revenue, extend marketshare, increase customer satisfaction are all good objectives.

The challenge we face is how to objectively evaluate the myriad of feature requests that come across our desks. The problem that I’ve seen far too often is that the discussion or debate is focused at the wrong place. Instead of debating whether the feature should be in or out, the debate should be around how well a feature meets the business and/or release objectives. Here are examples of a couple of objectives that I found to be very useful:

• Improve Sales Wins – this objective speaks to the idea of winning more sales engagements. Some features absolutely shine during the sales engagement and others have no impact whatsoever. Features that shine are either very demonstrable or the sales team can speak to them with great impact. Another way to think of this is a resonation factor – features that resonate with the prospect. So the debate surrounding a feature is now, on  scale of 0, 1, 3, 5 how well does this feature meet this objective? 0 – not at all; 5 – home run!
• Broad Market Applicability – this objective speaks to the broadness of the applicability this feature has with the target market. In other words, you want to add features that apply to as many of your target markets as possible – outliers are not necessarily a good thing. Again, on a scale of 0, 1, 3, 5 how many markets does this feature resonate with? 0 – none; 5 – all of them!

You can add more objectives like these two – I recommend no more that 5 – 7. You can have one or two that are product oriented in nature … word of warning – do not make them too granular, go with something that adds or improves a capability that is a key component for your target market. And lastly, you want to apply a weighted formula to calculate a total score. If your corporate objective is to win more new-named accounts, then weight the Improve Sales Wins higher – that way any features that really help meeting this objective will be ahead of other requests.

The result will be that your scarce resources (development, qa, documentation, etc.) will be focused on the features that help your company achieve its goals.

Building Successful Product Management Teams

I just had an interesting conversation with a friend of mine about the various activities product management performs within companies. He was fairly new to product management and was only ever exposed to the technical side of product management. Product Managers go about their daily, weekly, monthly activities – which are primarily in the tactical space … requirements gathering & documentation; working with the dev and sales teams; creating collateral; etc.; etc. Occasionally Product Managers get the opportunity to lift their heads into the strategical space and perform activities such market analysis; competitive analysis; etc. But by and large their focus is on the tactical activities.

But how do product managers determine what it is they need to do and when? How do they know when to go deep and when to pull back? People in charge of product management – typically directors – see product management from a different lens. They define what their product management team does, when they do it and why they do it. In other words one of the main responsibilities they have is the definition, implementation and training of the process within which the team operates. This typically takes anywhere from 30% to 35% of their time. The other responsibilities that they have is people and team management (typically 10% to 15%) and product strategy (typically 50% to 60%). Team management includes such tasks as mentoring / coaching; objective setting; performance reviews and product strategy is about the long term health of the product (i.e. strategy, roadmapping, prioritization, etc.).

As a director or someone in charge of a product management team are you slicing your time like this? Is something differently working for you?