Category Archives: business-driven product management

Can you feel the business in your finger-tips?

A handful of companies ago the CEO asked me, the head of product management, if I could feel the business in my finger tips. He went on to say (while rubbing his thumb over his finger tips) that you need to be able to feel the business on the tips of your fingers. I’ve kept that phrase with me for all these years and have asked the many product managers I’ve mentored over the years the exact same question.

What it means is that you get to the point where you have so much information about the business you are in that making product decisions is easy and that you can make them with such a high degree of confidence, you just know it is the right decision. Connecting the dots, developing strategies and tactics all come easy and natural. It does not come over night; it does not come by reading reports; it does not come by learning how the product works. It comes by getting out of the office and talking to people that are connected to your business – customers, partners, prospects, analysts, subject matter experts, and anyone else who is associated with your business.

Right from day 1 as a product manager in your new company make it a habit to talk to these people. Schedule on a monthly basis to visit (face-to-face) at least 4 customers – find out about the day in the life of a user; find out their challenges before they started using your product; find out how your product has impacted their business. Arrange with the sales team to sit in on 3 sales calls a week – don’t dominate the call, don’t influence/derail the selling process … listen and learn; contribute when asked. Attend regional sales meetings and user group meetings. Seek out the subject matter experts in your business domain, and take them to lunch or dinner. Ask them anything you want about your business … including what they think of your company and your product. Sit in on all of the webinars from the analysts in your business domain. Some of it may be directly relevant, some may not – the point is to understand your business and the bounds of your business (how do you know the boundary if you don’t know what’s beyond).

How do you know when you’ve reached this state? Good question. A lot has to do with confidence. You all of a sudden wake up and realize you’re there. You can answer every question confidently without saying “I’ll have to get back to you” … maybe that’s it. Every individual is different, but if you work at it you will get there and at some point you will realize that you are there.

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.

Transitioning to a product model

I met with another company that is struggling to transition from a services based business model to a product based business model. Many hi-tech companies start out with a single contract to provide a solution to a particular client. They find more clients that need to address the same set of requirements … sort of – the solution is customized for each and every client. The net result is a handful of one-off solutions to different clients that address roughly the same need. Revenue grows; number of new-named accounts increases and now it is time to scale the business to the next level. Clearly creating these one-off solutions is not a scalable model – you are bounded by your development resource pool. The transition from a professional services driven model to a product-driven model needs to take place. A product-driven model revolves around the sale of a single (possibly configurable) product to customers who have the same needs, or problems that need to be solved. In other words, you develop a single product that you sell to many customers in your target market.

Sounds simple! But there are many challenges to making this transition … here are some of the key challenges:

  • Moving away from the culture of ‘Yes’ – in a professional services model your goal is to secure that single contract and so saying yes to the wishes of that single customer to win that contract is paramount. In a product-driven model your goal is to sell your single product to as many customers within your market as possible. This means that you have to learn to say ‘No’. When a customer requests something, you have to determine if it has broad market applicability – if it does not have broad market applicability, then saying ‘No’ is your best answer. Why? You have finite resources and they need to be laser-focused on meeting your goal to secure as many customers from within your market as possible … divergences that do not move you towards your goal is a waste.
  • Changing the feature debates – if the customer, in the professional services model, decides where you should deploy your development resources; who decides in the product-driven model? Clearly you make the decision; but at what level do you decide what to put in the product? Far too often the debate rages at a very high level, i.e. each of development, marketing, sales, customer support, etc. have their own top priority item that must go into the next release and so the discussion ends up being opinion-based. Business-driven product management brings the discussion level down to the objective level, i.e. the debate needs to be centered around how well each feature request meets a set of business objectives. The end result is that the business objectives control what goes into the product – not some subjective opinion.
  • Assigning new ownership – in a product-driven model, product management owns the product. In other words, through their deep understanding of the market, their ability to objectively analyze requests, and with their full and complete view of the product, product management decides what goes into the product. The owner in the professional services model is the project manager or the account manager and their responsibility is solely focused on the client … not the market.
  • Developing a process-driven approach – process has been given a bad rap. No one wants to be process heavy. On the other hand, a lack of process will not deliver the repeatability necessary to become a product-driven company. The process in this case is the clearly defined steps you go through to decide what features to put in the product, the interaction between product management and development. This process is the core of a product-driven company – if it does not operate efficiently and cost effectively, then delivering your products on-time with the right feature set to meet your goals will be a struggle.

Let me know if you can think of other challenges. Maybe you have an experience you would like to share.

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.

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.

Welcome to Ateala Management

Welcome! Ateala Management is a new company with lots of product management / product marketing knowledge and hands-on experience. Our goal as a company is to make you successful. We do this through providing consulting and training services to ensure that you have a business-driven product management process. The determination of what goes into your product over its life and the on-time delivery of each release will translate into happy customers and your ability to expand in your existing markets and attack new markets. This in turn drives revenue growth and market share expansion.

Keep coming back to this blog to find out what business-driven product management is all about.