Politics and your next release

by Steve Johnson

A desire not to butt into other people’s business is at least eighty percent of all human ‘wisdom’… and the other twenty percent isn’t very important.—Robert A. Heinlein, author

You’ve planned a new release, pulling together ideas from the market and from the company. You think you’ve got a really strong plan but as soon as it’s announced, the complaining begins. “Where’s my pet project?” “When are we going to fix security?” “But I promised this feature to a prospect!” “Waa waa waa!”

Never forget, a product release is always political. To be successful, every release needs something to appease each of your internal stakeholders.


Now I know many product managers want each release to be purely focused on the needs of the market but prioritization inherently has a political aspect. Prioritizing explicitly says one thing is more important than another. Someone is going to be disappointed since there are so many who want their idea at the top of your list. After all, there are many folks in your company who think they know exactly what the product should be.

Here’s one solution.

Every product release should contain at least one big thing for each of the product stakeholders.

  • Strategic feature: one that aligns your company vision or portfolio strategy
  • Buyer-oriented feature: a new capability that appeals to buyers (and their sales people).
  • User-oriented feature: one that improves the usability or adds a new capability. After all, people who pay maintenance or monthly fees expect some of their money to go to new stuff, not just for support.
  • Architectural feature: one that makes the product easier to maintain for our internal teams. Sometimes this is about fixing clumsy code or improving security or reducing some annoying defects. Or adding capabilities and diagnostics to make the product easier to implement, service, or support.

(Ideally one or more features would also mess with the competition.)

These four items are the ones you emphasize in your roadmap and your internal communication.

4 features

One development team said they needed nine months to fix all sorts of internals and address years of technical debt. But rather than just “going dark” for a year, the product manager blocked out the major areas that needed to be addressed and roadmapped them. They allocated time and money for new stuff as well as the internals. They met the internal needs and also their political needs.

One thing for vision (and for executives), one for buyers (and sales people), one for customers (and your support organization), and one for maintenance (and development). It’s a good release.

One of my favorite sayings is, “Nothing seems hard to people who don’t do it.” [Tweet this]

Prioritizing is one of these. One sentence from an executive results in months of work for the product team. Not every idea can be the number one priority. Build a release plan that has something for each of your major stakeholders and you’ll get better buy-in to your plan.

About the author

Steve Johnson is a recognized thought leader and storyteller within the technology product management community. At Under10 Consulting, he helps product teams implement product management in an agile world. Sign up for his inspirational newsletter.

What is a Successful Product? An Overview of Metrics and KPIs to Track Product Success

by Anders Linsdorf

metricsEvery company wants to be a success, and of course, that means having successful products.  But what is a successful product?

Different companies will have different goals and it’s critical to measure and track product performance to achieve product success. While there can be many possible measures (metrics), the important ones are called KPIs (Key Performance Indicators), and finding the right KPIs and avoiding so-called vanity metrics is critical.

What’s your “On Base Percentage”

In Michael Lewis’ book Moneyball, the Oakland A’s changed their scouting and talent acquisition philosophy to focus on only one metric. In the world of baseball and the hundreds of possible metrics you could use it sounds like insanity.

Nevertheless, the philosophy went from the premise that the number of bases earned is what wins games; not number of home runs hit,  or number of stolen bases or any other metric.

It all came down to one thing: “on base percentage”.  How often will the player gets on base?  This insight allowed the Oakland A’s to perform WELL above average given their limited budget and exploit some loop holes in the market.

This is a powerful reminder that focusing on one thing can be very powerful. It will eliminate discussions about which of the KPIs is more important in case one goes up and another goes down. It will also ensure that everyone is on the same page and no-one is in doubt about what success looks like. So the first step towards product success is to find your “on base percentage”.

Different types of KPIs

There are two main types of KPIs: objective and subjective. They have different properties and can be used in different circumstances.

Objective KPIs are the best, because they pick out a measure that can be verified regardless of human perception and interpretation. They are things that can be measured like: frequency, volume, amount, duration etc. Most of the classic web analytics and economic parameters fall in this class. A good example of an objective KPI is downloads per day for an app. There is no way you can argue with that. The same goes for units sold per day.

Subjective KPIs measure things that depend on human assessment and interpretation. This does not mean that they are less quantifiable. When you measure customer satisfaction, there are many good frameworks for doing that. It could be Facebook likes, retweets, NetPromoter Score, shares etc. These are all quantifiable measures of a subjective quality, whether that is satisfaction, interest, pride or something else.

The business model determines the KPI

business modelThe absolute central KPI will always be monetary, like revenue, margin, or equity and the success of a product will in most cases be measured directly by the amount of value it generates.

Some people may object to money being the central purpose of a product, especially if they are of an idealist anti-capitalist inclination. But since money pays for salaries,  electricity, office space, health benefits, taxes etc, the success of the product must somehow be traceable to this.

Even if you are a non-profit charity organisation you need to pay the rent, electricity, salaries etc. Some products are offered for free and are viewed as successes even though they generate little or no revenue. e.g. Quora, Pinterest etc.  But the reason they are valuable in the eyes of investors is the promise of revenue, Typically the KPI is number of users. But this figure is usually coverted into revenue by a value those users can potentially generate. (eg. $10 per user per year). In that sense money is once again the measure for product success.


revenueThe most straight forward measure of product success is the revenue it generates. The reason is that it is the cleanest and most intuitive metric. Nobody can argue with that figure – money in the bank is money in the bank.

Sometimes revenue is more important than anything else, since you can’t argue with liquidity. Examples of these types of products are SaaS products where it is popular to track Monthly Recurring Revenue per product. That is an accepted standard. Traditional software companies typically track revenue from licenses sold.

Transaction-based companies like credit card companies or other types of infrastructure companies who charge by transaction may track the number of transactions or transactions per customer per month etc.

It may occur that the revenue is not directly referable to the product in itself. That is the case for many free products (but not freemium products).

A good example are open source software products. If we take the Cassandra database as an example, it is free and can be downloaded. It is built and maintained by Datastax which received a very large round of funding recently $106 million ($189M in total). You could track Cassandra’s success in its installed base.

Then again, most people need support, since it is after all a complicated product, and guess who is selling SLAs, support and implementation consultancy for Cassandra? Datastax of course, so again the KPI  (installed base) is a proxy for revenue.

More interestingly this creates a drive towards making the product more needy of consultancy, so what looks like a successful product to the company is not necessarily the same to the customer in this case.

Revenue is a good around indicator if the business model dictates you earn money on all the units shifted.


calculatorRevenue is not always an indicator of business success as you could be selling products for a lower cost than the production cost. More sales would therefore not lead to success for the company.

Margins are a more precise way of tracking product success because they directly support business success. Margins are typically calculated as profits/revenue. i.e. profitability can be tracked as revenues grow.

It is a good thing to track margins when cost per unit is easy to calculate. That is usually the case for hardware and physical products, where cost per unit is often already calculated.

So, in the manufacturing industry that would be a good measure. The same goes for retail, where the cost per unit is the purchase price, plus transport and storage. Sometimes the margins are just calculated as the purchasing price minus the sales price. That is good rough measure of success.

In other industries, like service industries, it is a bit more difficult. If we take a hotel, the cost per unit is somewhat more difficult to calculate, since heating, cleaning and electricity is not typically calculated per room.

The same goes for professional services, where one hour sold may have the cost of the consultant for that hour, but also all the other hours he or she didn’t bill to any customers and that amount is very variable.

Margins are a good KPI for industries where the Cost per unit is easy to calculate and intuitive to understand.


pieceofpieIn some cases revenue and margins may fall short as measures of success. To measure product success in terms of equity is more prevalent in isolated fields.

In accounting terms, equity is the the amount of liabilities minus the assets. For a product that would mean how much you owe (for buying, producing, building etc.) minus the market value. That doesn’t make much sense in terms of serial produced products like cell phones.

If we take real estate it makes a lot of sense. If the product is a house or an apartment, the ability of investments in this apartment to raise the market value is a very good measure of success.

Something similar is also the case for incubators, where the start up itself is the product. Here you may want to track the investment against the market value in order to see whether the product is successful. I would guess that Y-Combinator, Rocket internet or 500 start ups would track the equity of each individual start up rather than their revenue or margins.

One problem with equity though is that market value may be very hard to assess before you sell the product. That makes it hard to use as a proactive KPI. But usually there are other proxy indicators. In consumer technologies, the standard one is number of users, downloads, visitors etc. because that can be used to calculate predicted revenue and therefore market value.

Equity is a good measure if the product is unique.

Non-monetary measures

sat-smileThere may still be instances where you would measure product success by some other KPI, which is not monetary.

One example is satisfaction. Many products from state departments are offered as a service to citizens. They are still products, but they do not generate any revenue, margins or equity, indeed, they were never meant to. Instead they generate a service, the success of which can be measured by satisfaction in one sense or another.

Satisfaction is somewhat more difficult to measure, because it depends on subjective measures.

A rating scale is a typical solution, but it could also be sentiment analysis from social media or clicks on icons such as likes and smileys. Number of issues registered or complaints related to a product would be another way of tracking satisfaction.

Sharing on social media is similarly usually a good indication of satisfaction, but you can’t tell whether it is shared because of a positive or negative experience.

Some public sector products are however not meant to have high user satisfaction ratings: Jails will not be measured by user satisfaction either, since the users are meant to not have great satisfaction from it.

Non monetary measures are good when the business does not generate it’s operating budget from the product.


Product success is key to the success of the entire enterprise. You should carefully study the business model of the enterprise and pick just one KPI as the measure of success. The KPI should be quantifiable and possible to track continuously. Otherwise you don’t have anything to steer after.

You could and should still track other KPIs if they in some way influence the central KPI. That way you can learn the best ways to optimise your product and see early warnings of problems.


NOTE: This article was originally published on SensorSix.com. An edited version is reprinted here with permission of the author.
Tweet this: What is a Successful Product? An Overview of Metrics and KPIs to Track Product Success http://wp.me/pXBON-49v #metrics #kpi #prodmgmt 

About the Author

 anderslisdorf-bwAnders works to to turn new innovative ideas into the reality of tomorrow. His company, Sensor Six, makes software to help companies develop new products.

Product Management – You’re doing it wrong

by Saeed Khan

Italy Cruise AgroundWould anyone hire a sales rep, have him spend his time updating the website and then wonder why the sales aren’t coming in?

Or how about hiring a accountant, asking her to project manage the development team, then question why the books aren’t up to date?

Or how about having some of the software developers spend time crafting marketing emails and then ask why code is delivered late?

Or lastly how about hiring a product manager and having her update the website, project manage the development team and craft marketing emails and then wonder why the product strategy and roadmap are not effective and complete?

Well, the first 3 are pretty much non-starters, but the last one — product management — is unfortunately far too common at many companies, and shows a clear dysfunction when it comes to defining product management responsibilities.

Product Managers have spoken

The results of our survey — What keeps product managers from being really effective? — paint a pretty clear picture of this dysfunction, with product managers doing everything from technical support to project management to, as several people put it, “janitorial work”.

Why are people hired to focus on the success of the product, for both the short and long term, getting mired down in duties that, for the most part, have little to do with the reason they were hired?

Product Management IS a cross-functional role. That DOESN’T mean Product Managers should do the work of other teams.  It DOES mean that they should be ensuring that work is being done by the right people and is aligned with overall product success goals.

Success requires coordination

To maximize product success, 4 areas must be aligned. These are:

  • Business activities and objectives
  • Organizational readiness (internal and external)
  • Go-to-Market plans and activities
  • Product plans and capabilities

Each of these breaks out into a number of activities and deliverables, some of which must be done by Product  Managers, and others which are done by other teams under the oversight of Product Management. If Product Management is not focusing on aligning and optimizing these areas for each product, then your company is losing out on top-line value.

Management needs to make sure the work that SHOULD be done by other teams is ACTUALLY being done by those teams and not by (typically understaffed) product management.

Otherwise, you might as well ask your sales reps to start working on that website. The business benefits will be about the same.


Tweet this: Product Management – you’re doing it wrong http://wp.me/pXBON-4eC #prodmgmt 

About the Author

Saeed Khan is a founder and Managing Editor of On Product Management, and has worked for the last 20 years in high-technology companies building and managing market leading products. He also speaks regularly at events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page on this blog.

UX and product managers


On the Mind the Product blog, Martin Eriksson writes,

I’ve always defined product management as the intersection between business, technology and user experience. A good product manager must be experienced in at least one, passionate about all three, and conversant with practitioners in all.

To Martin’s list I would add expertise on the market (or persona) and a passion for the domain. I’ve written about expertise in product management in my free ebook. (Download it here).


User experience (UX) is an area that befuddles many product managers. Ideally, product managers should be focused on the customer problem while development designs the company’s solution. A strong dev team will propose one or more solutions to the articulated problem, allowing the product manager to accept the best option by leveraging his or her business, technical, marketing, and domain knowledge. A UX designer is a critical element of a successful product team.

If you’re interested in UX design (and all product managers should be), take a look at The User Experience Guidebook for Product Managers from the helpful folks at UXPin.

The difference between good and great is often in the user experience. Let’s all become passionate about brilliant UX design.

About the author

Steve Johnson is a recognized thought leader and storyteller within the technology product management community. At Under10 Consulting, he helps product teams implement product management in an agile world. Sign up for his inspirational newsletter.

Stop saying “No” and start asking “Why”

by Saeed Khan


Every day, it seems, I see another blog post or article on product development that tells people to say “No” to feature requests.

Don’t believe me? Just do a web search on Say No to feature requests, or something similar, and you’ll see what I mean.

This advice to say “No” started, I’m certain, with this quote from who else but Steve Jobs.

“Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.”

Jobs said this to a group of people from the music industry, who, when showed a preview of the iTunes Music Store, started asking about potential feature enhancements. “Will it do [this]?”, “Will it do [that]?” etc.

This line, like the famous Ford faster horses line that Jobs also spoke about, is definitely a truism, but doesn’t constitute a hard and fast rule, dictating to people that they must say “No” to feature requests.

In the Jobs’ quote, he was simply explaining what he (rightly) believed about the innovation process.

“Why” is better than “No”

Instead of simply saying “No”,  people need to ask “Why?” and try to truly understand the reasons behind the request.

The people making the request should have a clear reason (in their mind) of why they’re making the request, and it is incumbent on you to find out.

Feature requests are pre-conceived solutions to problems. Asking “Why?” (as many times as needed and in as many different ways as needed) will get to the heart of the problem.

And only then should a Yes/No decision be made.

And even with a “No” decision, it can be “No, right now we have other priorities, but we’ll definitely consider it in the near future.” response. i.e. “No” is not always an absolute “No”

The more you understand “Why”, the more context you gain over time at underlying patterns. Different feature requests may simply be different perceived solutions to the same problem.

You’ll never realize this without asking “Why?”

So while I agree that we should say No to non-crucial items, you’ll never know what is and isn’t crucial unless you understand why.


Tweet this: Stop saying “No” and Start asking “Why” http://wp.me/pXBON-4cJ #prodmgmt #innovation

About the Author

Saeed Khan is a founder and Managing Editor of On Product Management, and has worked for the last 20 years in high-technology companies building and managing market leading products. He also speaks regularly at events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page on this blog.