Tag Archives: business objectives

The Two-Word Value Proposition

Here I go again blogging on something in the area of Product Marketing … I should leave that up to April Dunford the Product Marketing expert; but I can’t help myself.

Can you create a two-word phrase that describes your value proposition? Something like ‘Change Ready’ or ‘Threat Resistant’. You should be able to attach them to the end of the phrase ‘Are you …?’ or ‘Is your whatever …’. You then can use phrases that contain these two words when you talk to a prospect or add it to the front page of your web site. Or maybe even trademark it.

The first word needs to describe the problem that you solve or the desired outcome and the second word needs to describe your solution to the problem. The problem, of course, has to be expressed from your target market’s perspective … i.e. it can not be what you do (no one cares about that).

My company – Ateala Management – helps tech companies with their product management issues. Outside of the realm of product management nobody gets this. The usual response is “huh?”. My target companies are those that are just beyond the start-up phase looking to scale their business to the next level. The problem they have is staying focused on meeting their business objectives with all the distractions being thrown at them. What I do is implement systems and processes and educate their staff to focus on making decisions that help in meeting their business objectives. I now ask if  they have an objective-focused business. So my value proposition can be condensed to “objective focused”. Is your business objective focused?

Try it with your product. Can you share your two-word value proposition?

Is your Product Management process Agile?

I’ve read many articles on whether product managers need to become agile as the development team embraces an Agile development methodology. Saeed wrote a great article for the March ’09 pragmaticmarketing.com newsletter proving that, in accordance with the Agile Manifesto, product managers have been living the elements of the Manifesto for some time (but may not have known it). Having been with companies that decided to ditch non-Agile methods and embrace Agile development the biggest challenge for my PM team was not for the product managers to become agile (or more agile) but instead the timing of when they perform their activities. Long gone where the days of a 6-8 week planning cycle where product managers brought everything to the table and the horse-trading began. It now meant that the team had to on a regular, timely basis (synchronized with the iteration cycle) prioritize new requests for the backlog, analyze the current backlog, and describe the usage scenario and key requirements as quickly as possible … as well as meeting with customers, performing market research, liaising with the development team on the work items of the current iteration, etc.

It also meant that the team became engaged with the project throughout its lifecycle on a more consistent basis instead of cyclical as was the case with the non-Agile method – i.e. the PM resource loading for the project remained relatively constant. It also meant that they needed to iterate through the requirements gathering / analysis / documentation process. First was to understand the top 5 requirements that meet the request and convey that to the development team. Next was to drill a little deeper in areas where dev neede more understanding. And lastly was to stop, when dev understood what was needed (I recommend reading Lean Software Development by Poppendieck – it provides a great discipline for this type of an environment).

In order to become business-driven in an agile world, product management processes need to be tuned so that product managers can perform all the activities that are needed so that business objectives are met.

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!