Musings on Software Product Management and Marketing

Is this blog still alive? Of course it is!

2011-12-31T23:23:00.000-08:00

Contrary to what it might look like, it really is. Right after writing the last post on "Design for the novice, configure for the pro", I accepted a new job with Nimsoft that has kept me rather busy including professional blogging obligations. As such, I've neglected this one. However, I have been pleased to see it continue to get steady traffic in the meantime.

The upside (for the blog) to being really busy is that it has given me a bunch of new ideas to blog about here. Watch for these in the new year.

You will also notice that I now have a professional URL here for the blog. From now on, you can use blog.pmmusings.com to reach this screed.

The formula: “design for the novice, configure for the pro”

2010-12-03T00:11:00.000-08:00

Mark Suster has a line in his recent blog that I think perfectly captures the ideal design goal for software:

“Design for the novice, configure for the pro”

I think that with this simple statement he captures the direction we all need to be heading to produce successful software design. Particularly in enterprise software, we are always conflicted between putting the newest and most powerful feature front and center and the resulting complexity that puts off users.

By keeping this philosophy in mind, we can help guide our results to something that approaches well designed consumer software in its simplicity and yet meets the requirements of at least the majority of the power users.

The best examples in modern software are IOS applications. Have you ever seen a manual for one? No, well you won't for the vast majority. They aren't needed. The main interface and functionality are constrained to do the task at hand (or finger, as it may be). It has to be self evident because there isn't room for more options. And if the user doesn't 'get it', it is game over. However, some of these same apps have some major configuration options, that change the nature of the app, hidden behind the gear icon. My favorite example was setting up a tethering-router app. This does the same thing that the PC app I purchased a dozen years ago that came with an inch thick manual. But I was up and running in a few self-evident steps.

In the past, a common solution in enterprise software has been to provide 'role based' interfaces for different levels of user. However, in some cases this too, causes problems for the inevitable 'tweener' who needs more than the basic but it confused by the 'open class' UI.

The idea of a personalized, configurable experience is ideal. Initial rollout can be with the normal, simple, elegant (we hope) model. But as experience drives a desire for more power and flexibility, additional aspects can be turned on or configured to suit the need. Done right, these configurations are simple parameters which are relatively easy to manage in a SaaS, multitenant environment and/or through upgrade cycles.

Yes, this complicates the software design quite a bit, but that is part of the point. Lets do our work up front to focus on what is really needed and hide the complexity for where it might really be needed.

"Sucks Less" Features

2010-03-30T18:48:00.000-07:00

We all have them. Those things that need to be done to improve the product but they just aren't exactly exciting to the customer.

They might make a huge difference in the performance or quality of the product.
They might resolve that thing that customers have been annoyed about for ages.
They might even be really cool from a technical perspective

However, they are not something that you can promote to your customers as a great new thing. They are "sucks less" features. As in, this thing now "sucks less" than it did before.

Sure, the term reflects a cynical attitude. But, it also gets people's attention, particularly in-house (the only place the term should be used, frankly). I like to use it because it helps people realize that although this feature may be helpful or even important under the hood, at the end of the day, what the customer sees is that the product is only mildly improved. It sucks less. You better have something else in the release to really get people's attention.

Where should Product Management live?

2009-12-11T00:59:00.000-08:00

In my experience, this is one of those things that is bound to never be resolved. Not in the industry and not even within a single company. However, it makes great fodder for theoretical managment discussions and reorgs.

Frankly, in a small organization I don't think that the reporting structure matters nearly as much as the people involved. If you've got a good PM (or two) in a small organization, they will get the respect and attention from the people who need to give it.

However, in bigger companies, I believe that where PM is placed has a tremendous impact on the scope of the role and ultimate effectiveness. Here are a few of the pros and cons of the common organizational ideas:

Reporting to VP of Engineering

This is probably the most common scenario of them all. However, despite that commonality it has some structural flaws.

Pros:

Closely coupled with the dev teams to get good feedback, scoping estimates etc.
More likely to participate more granularly with the project while underway because you'll be on the same teams.

Cons:

No check and balance in the system.
When PM reports to engineering, it can become very difficult to champion something that perhaps the market, customers, etc. need that isn't thought necessary by the developers.
PM loses the 'stick' to prod performance to plan etc.

When PM reports to engineering, it tends to produce a team that is highly technical and project focused. However, it also yields PMs who are less connected to customers and the field and a large gap to their partners in marketing (product or otherwise)

Reporting to Marketing

In my experience, this is the second most likely configuration

Pros:

Generally produces PMs who are aligned with market needs
Good field engagement
Close ties to marcom resources etc.
Provides a balancing force to engineering. The power over the product is split which forces more conversation and compromise over all aspects of the plan

Cons:

PMs reporting to marketing tend to get cut out of the loop with engineering. Not participating as well in project meetings, resource adjustments etc.
It tends to produce a less technical PM team which may or may not be a problem depending on the product. But the perception alone will hinder the working relationship with engineering.

Reporting to business management (CEO or GM)

This is what I believe is the best answer. Sadly it is also probably the least common configuration in tech businesses.

Pros:

Addresses the balance of power issue even better than reporting to marketing
Leads to strong PMs taking a holistic business perspective. It isn't about just managing the requirements or the project but rather figuring out what is best for the business.
A seat at the same table with all relevant partners: Engineering, Marketing, Sales, Support, Services, etc.

Cons:

Frankly, the only issue I can see are related to the quality of the PM leadership (it better be good)

If you have any thoughts on the relative merits of these scenarios or your experience with them, please add them in the comments.

Don't rely on technical features to market your product

2009-10-14T09:30:00.000-07:00

As part of marketing their Chrome browser, Google recently did some research into whether people actually understand what a browser even is. As you can see from the video, the answer was "no" for 92% of the people they interviewed in 'man on the street' interviews.

Above: "Man on the street" interviews by Google about browsers.

So, they are trying to market a product to people who don't even understand that there is a product. At that point it doesn't matter that it is free. Free is still too expensive when there is no customer identified need being met.

When we market technology products most of us (oh yes, me too) have a tendency to follow on the features in the latest release and try to show how cool, useful, valuable [insert favorite word here] they are.

"Seriously, the double speed super widget is fantastic. It is twice as good as anyone else has"

So what?

If there is an identified market of people who have been asking for a "double speed super widget", then fine. Just tell them and they will buy it. Let's just call that "Field of Dreams" marketing. But most of the time we are selling into an established market where there is competition and perhaps even an incumbent solution to the users' needs.

By focusing on the feature, we fail to approach it from the customer's perspective.

Instead, we need to focus on what the customer needs. In Google's case, they have a tough time here. Everyone has a browser. Chrome has a few advantages like speed but a) how many people care and b) that's just an endless arms race. They have to find something that is more compelling to their users and without making 'evil' tie ins to their services this will be hard.

What about your product? When you start preparing a launch plan, or even in the MRD/PRD phase, do you evaluate the features and what's cool about them? Or do you ask what does the customer care about?

Let's take the browser example. I'll take a few liberties to make the point. Let's say that the new browser supports a new flash player that runs twice as fast as the competition. You could market that as: "New Browser Has Twice the Speed of Competition". But, do your customers know they have a speed problem? Probably not. Modern hardware is too fast and the prospective customer doesn't know whether it is the incumbent browser (what's a browser?) or the internet or what is the cause of any lags they perceive.

Instead let's look at what the customer sees. Let's say you've surveyed customers (how is another post entirely). They complain about herky jerky video and animation on many sites. You know that it turns out that much of that is the CPU load for interpreting the Flash video.

So, try this pitch instead: "Everyone Can Play Online Video Smooth as Silk". The message addresses a customer pain point. Only deep in the message tree do you explain the whys and hows of this great new feature.

By starting from the customer's perspective, you can avoid the worst of 'geek marketing' problems. You might even design a better product in the first place.

This post was originally inspired by this Slate article.

Prioritizing features is the last thing you should do

2009-09-25T16:23:00.000-07:00

Jeff Lash has a good post (Product Management is More Than Prioritizing Features) that focuses on probably one of the key deficiencies of poor product managers. I actually agree with most of his post, but don't think he takes it quite far enough.

He describes the trap of PMs who think that their job is to simply compile and prioritize a list of requests from others - customers, sales people, support, execs, etc. I'll call this type of PM a listmaker. I have found listmakers to be widespread in junior PMs and in dysfunctional PM organizations. Listmakers are doing much more Project Management than Product Management (all you quality project managers out there, please don't beat me up for shortchanging your discipline, I'm trying to make a point).

Hearing this set of feature requests and paying attention to them to create 'the list' is, in fact important. However, you can't possibly do it right if you start (or finish) there. The key is how do you prioritize what really should be done?

Listmakers will sort the list by some sort of seemingly justifiable algorithm. Perhaps based on the number of references to an item, perhaps based on how long it's been there, perhaps based on who's yelled the loudest. All of these make sense to a point. Many of these even make sense for that bucket of 'sucks less' features that I think should be part of every traditional (i.e. big release, not an agile sprint) project.

However, it does not make sense for really taking your product and your company to success. For that, you have to be able to see the bigger picture. You have to ask and answer questions like:

Where is the industry going?
What is going to matter in 1, 2 or 3 years?
What is the innovation that will change the business?
What is the competition going to be doing when this launches (yep, get out that crystal ball)?

It is really about strategic thinking and planning. That has to drive the product. Looking at the individual feature lists first will lead to the fabled problem of not seeing the forest for the trees block the view. The right sequence is:

Plan your roadmap. This is a 1-3 yr rough plan of what you need to do based on the kinds of questions asked above. It may very well be wrong by the time you get to years 2 and 3. That's ok. It still provides a foundation of consistent thought for the team to work from
Plan your releases. Figure out what should be packaged together into each release opportunity. Maybe it is driven off of a marketable theme (see "Write the press release before the code" Maybe it is based on what bits of effort make sense to do together. But either way, start with the big and/or important parts first.
Once you have that framework in place, the Listmakers can come to the fore and help to make sure that the requested features that tie to the theme are prioritized into the project (or not). After laying the strategic groundwork, it is safe and appropriate to be tactical.

Related Posts:

Clever Promotions Work

2009-03-31T11:54:00.000-07:00

In a post back in January, I commented on Hyundai's timely "Hyundai Assurance" program. Well, the early results are coming in: It worked.

Hyundai initially reported sales up 20% in January and closed the month up 14%. And this in an environment of car sales collapse.
Today, both GM and Ford offered programs with similar intent. It is said that imitation is the sincerest form of flattery. It should be noted that these new programs do take a different spin. Instead of allowing the return of the car, they offer to make payments for 9 to 12 months if the buyer loses a job. Let's see if this helps them too.

Customization leads to failure

2009-03-16T17:45:00.000-07:00

What is the leading cause of product failure with startups?

Well, I don't have the quantitative research to prove it, but I would guess that somewhere near the top is over-customization to suit the needs of 'important' customers.

You probably know the drill:

Create vision and product plan
Try to sell product
Meet great prospect "Brand X"
Try to close the deal and learn that they would pay you a gazzillion dollars if only you would...
Agree to "Brand X's" requirements and incorporate them into product
Repeat

Now, I am the last one to say that you should not listen to customers. Nor should any company - particularly a startup - walk away from good money lightly. However, this kind of cycle can cause tremendous long term damage to the company both in terms of culture and product.

Cultural issues

I've seen several companies go down this path of following the desires of their lead customers. While I'll admit that sometimes this has been the key to finding a 'true path' and corporate success, it seems that more often it leads everyone astray.

Problem 1: You don't sell what you have. When you start customizing for many customers, you breed a culture in the sales organization that they can find any loosely fitting prospect and the company will do what is needed to close the deal. This is not healthy.

Marketing (including PM/PMM) should be working with sales to figure out how to identify and lure good-fitting prospects that align with the business strategy and product strengths. The sales team should be educated in how to effectively screen prospects for fit right up front along with inspecting the prospect's budget.

Problem 2: Lack of focus on the business' strategy. All of the cycles used for negotiating and delivering the customizations takes away from time on the core strategy. It can even make the strategy irrelevant.

It is important for the leaders of the company to constantly evaluate the requests for customization. Sometimes it might be the right answer because of the customer or because of the great new direction it takes you but it should never go against the strategy.

Product issues

Problem 1: The product plan goes off the rails. Unless you are awash with resources and can carve off core and customization teams, all the custom requests will inevitably push plans off track. This can be better managed in a short-cycle development process like Scrum but it doesn't change the long-term impact.

Problem 2: You don't do what you need to do. This is really the biggest problem. If you believe that success depends on implementing robust versions of a certain set of functionality, you have to make sure you get there in time. Diverting resources to short term gain only makes sense if that is what is needed to survive.

Problem 3: Your product becomes a muddle. Too many customizations that get incorporated into the product are likely to muddle up the core model of the product. The underlying architecture gets messy. They user experience gets cluttered by special functions, etc.

Problem 4: You never had a strategy to divert. Well, I think you can guess what the problem is here.

The other death spiral

2009-02-18T17:32:00.000-08:00

I think many of us know about the financial "death spiral" (the most popular version in the Valley these days is attributed to Sequoia Capital - see slide 49 in particular). While this is scary and real, I am referring to a more internal problem to people and organizations. One that anybody involved with the company's strategy should be particularly wary of.

This death spiral is where you start to believe too much of your own thinking. We've all done it to some degree or another. But the best of us see it and work hard to break it.

It often starts with simple statements like:

"We've always done it this way"
"This has been working"
"Oh, I just know this is the right way"
"It's not worth changing now"

Over years of experience -- particularly within a single organization -- a kind of inertia builds up. We have seen it before and figured out an answer so we just assume away elements of our decisions that perhaps we should not.

I think it is important to make a point of continually asking yourself and your colleagues the question you learned as a two year old: "Why?" Why did we do it this way? Why should we keep doing it?

It is quite likely that the status quo is that way for a reason. It really was the most efficient or most popular with the customers or best performing or whatever.

However, it's also entirely possible that it is not.

Let's take some examples from technology products:

First let's look at the case with a product that has been established and successful for a few years. Over time the technologies that it is built on become old. Or perhaps the model or approach taken five or ten years ago is no longer state-of-the-art.

The natural bias is to see this as the basis of the past success and keep going with it. The team questions why to burn precious development resources reworking what is already done.

Most of the time, this is good thinking. It preserves your advantage and gives you a chance to move ahead.

However, let's consider some cases where it isn't:

Platforms and Technology

What about the case where new entrants into the market have jumped on a new technology/architecture/whatever and are using that to win deals. Your installed base is happy to keep going but new customers get harder and harder to win. The competitor takes advantage of "NewTech" to whip out snazzy new features or just more modern UI elements that make their product feel better to your prospects. Meanwhile, your engineering team is bogged down with "OldTech" and says that those features are hard/costly/slow to implement. Are you spending more on maintaining and extending than it is worth?

Third party tools

How about where you are reliant on some third-party tool - say a reporting engine - for some functions and it is no longer providing competitive functionality. Or worse, it is no longer supported. Again, the tendency is to let it be. It works, it's done. But what about when you need an extension?

I use reports as an example because many enterprise software products are "sold" on the quality of their reports (and other visualizations of information). While it is tempting to say that the information is there and isn't worth re-doing, maybe your competition is out there using the same information to tell a more compelling story. Once again, you have to ask whether the ongoing, incremental costs are really better than a re-do, as painful as that would be.

Architectural issues

Sometimes the decisions made early in a product's life haunt it forever. For example, a lack of multi-tenant design makes it very difficult to even consider business models like SaaS or lack of proper Internationalization makes it hard to properly enter other markets (see post). Often, these are such fundamental decisions that it really never is practical to re-do the work. However, the question should be asked from time to time. Because, as the conditions change, it might become the right answer anyway.

What to do

Make periodic "assumption questioning" part of your routine process - No need to torment yourself or your team with endless 'navel gazing', but when the questions come up, don't just take the status quo for granted.
Take a step out side of your comfort zone - Ask the tough questions. "Is this right?" "Why is it right"
Really do a scenario analysis of how the options will play out over time - If you continue down the path what will be the consequences? What opportunities would be opened up downstream if you make changes? While change might not make sense in the short term, the advantage next year might be huge. Then again, this year may be so important that you can't afford to gamble on next year. Your milage may vary.

Oh, and if you do come to the conclusion that the past assumptions no longer hold, how do you make a change. You might not be looking at a "kitchen remodel" but something closer to a "teardown" project. How do you change the proverbial tires on the moving racecar? I'll leave that for another post.

Choice is good - Make the right ones

2009-01-26T12:20:00.000-08:00

I just read another great take on the importance of having a clear strategy and prioritization. (click here to read in a new window).

The author is focusing on the success that Apple has had with focusing on a relatively limited product line. He uses the 'insanely' complex product portfolio at Garmin for comparison. Where Apple has only a handful of products in each of a handful of categories, Garmin has made a different choice to create separate products for every sliver they can find.

I don't agree that there is only one right answer here. The 'Garmin scenario' is partly in response to the challenges of the distribution channels and a fast moving, young-ish market for consumer GPS. However, Apple's successes do show the value that can be achieved by focusing on getting a few things right.

As I mentioned in my previous post (Pick One Thing), I am a believer in the merit of focus. Not that this is easy to do. Personally, I am always tempted to try to 'cover the bases' because there is so much opportunity and often insufficient data. However, while opportunity is great, the reality is that resources are finite. Given that, spending the time to pick wisely and focus can yield the kind of success that Apple has seen.

If you look at Apple's product line, you will find that they have aimed straight for the middle of a couple of segments.

iMac => Just give me a good machine to work on. Very few choices, it just works and while having a premium price, it is 'in the zone' of expectation.
Mac Pro => I need more. Power, flexibility, etc. and I'm willing to pay for it.
Mac Mini => Cheapish, simple. I just need a Mac. No flexibility.

Notice that there is no product that is reasonably priced and flexible. They aren't trying to have a desktop PC where you can pick from this drive or that or this monitor or that and so on. Either you take a sophisticated appliance (iMac) or you are a high end player willing to pay (Mac Pro). Does this leave 'money on the table'? Maybe. But by being so simple and straightforward, customers who want to play in Mac-land just make the choice between the families instead of being indecisive and looking around to see if someone else might have something just a little bit closer to what they had in mind.

Doing this successfully does require a fair amount of care in deciding what the limited choices should be. I don't have insight into whether Apple makes these decisions based on substantial quantitative research or just on sensible decisions of subject matter experts. However, if you look at the choices made (when the products are fresh in their lifecycle - long cycles are a whole different conversation), I believe that they really hit the "what you really need" target quite nicely.

Compare this to Garmin's approach. I'll take Mr. Burns number that they have 82 products in two of their segments (car and hand held). I think the case that one of the commenters makes about how this is largely to give different channels their special version is probably true. However, it makes purchase decisions a real challenge. They are dependent on a channel that can limit or guide their customers to a decision quickly enough to not look elsewhere.

I consider myself a bit of a GPS geek (I've owned 5 so far not counting phones) and I can't figure out what they are offering. On several occasions I have thought about buying one that I saw written up only to become so frustrated by the options and permutations (at very different price points for slightly different features) that I decided it wasn't worth it. In fact, I ended up buying a less cutting edge one on clearance instead. Oops. That wasn't the goal of the marketing campaign was it?

However, the strategy seems to be working despite itself. Last numbers I saw had Garmin clearly leading the pack in market share in the US. They also have heavy saturation in most channels. While this is achieving the goal of winning the 'slotting' war on retailers shelves (or pages) but crowding out competitors, one has to wonder for how long and at what cost. Remember ten years ago when the PC companies were all about retail (the last time around) and were getting their clocks cleaned by 'on demand' models like Dell? The 'conventional' companies had too many choices, couldn't keep the right ones in stock, etc. As prices came down, they couldn't compete on cost or in having the 'right' choice in stock. Will Garmin face the same problem as the prices keep dropping? Or will the overall market grow fast enough to make each of those 82 products profitable? Time will tell.

Most of us are working with smaller markets with relatively fewer resources to spread around. The real question for us goes back to the headline: Customers want choices. But you have to choose which options you should give them.

Clever promotions

2009-01-09T15:08:00.000-08:00

This one is a little off topic but since most of us have at least partially marketing based jobs, figured it's fair game.

Hyundai Motors has announced a promotion that is targeted at these times. Given that many people who are capable of purchasing a new car are sitting on the sidelines due to uncertainty, they decided to attack it head on with an "Hyundai Assurance" program. This program says "buy a car now and don't worry". If you lose your job, drivers license, life, go bankrupt, etc., you can bring the car back no harm, no foul, no obligations. They'll cover up to $7,500 in negative equity on the loan or lease.

This just strikes me as a very clever way to address an unprecedented lack of demand. It's a potential game changer like the long warranties they've been offering to counter the old concerns about quality. I can't wait to see how well it works for them.

Full disclosure: I have none. I don't work for, invest in or own Hyundai shares or product (for now at least)

Pricing for the future

2009-01-09T00:54:00.000-08:00

A lot has been written in economic and business literature about pricing. You remember, find the market clearing price, factor in elasticity etc. All very valid economics but not exactly reality in a world where you are selling software to a few dozens of customers for many thousands of dollars.

In my experience, enterprise software pricing is as more art than science. This is true both of establishing pricing models as well as setting price points. However, there are some important best practices in that art. Here are my favorites regarding pricing models:

1) Align pricing with business value. This one seems so obvious until you look at what real companies do. Take companies that price their software on CPU counts. Jane customer says: "Hmm. So the worse performing the sofware is (i.e. it doesn't scale with me) the more you'll charge me". With the stipulated exception of an innately compute bound process, it makes no sense. Common scalar metrics are per application module and per user. Frankly these work pretty well because they are common and well understood.

However, models that tie directly to value are even better:

Per invoice sent
Per device deployed
Per dollar saved
etc.

However, some of these can risk violating #2, #3 and #4 below.

Annuity models where you capture value during successive time periods have their own innate business value connection in that they are paid as the customer keeps using (and hopefully valuing) your product. But this can be overlayed on the other metrics.

2) Make sure that the pricing makes sense to your customers (oh and your sales people while you're at it). If your sales team and customers cannot grok the intent of the pricing model quickly you are doomed to spend the rest of your tenure in the job explaining it over and over to the befuddled faces of people who are going to go write a custom contract that blows away your consistent model anyway.

3) Don't make it too complicated. Any econ geek worth his graphs will be tempted to come up with an 'n' variable model that factors in the elasticities and optimizes for nearly all situations. However, this will certainly violate #2 and possibly #4. Stick with K.I.S.S. models as long as they deal with #1, #4 and #5. A quick test is can you tell someone the model once and have them use it without further discussion. If not, try again.

4) Make sure you can actually and easily track (and enforce) the metric. This one is a classic, particularly for products where the model has changed. Somebody decides to charge per widget instead of per dingaling but has no way of counting widgets efficiently. This is bad for you because:

you will spend a lot of effort chasing the metric
you will annoy your customers
you will lose revenue

Not only that but you will incent non-compliance. The customer usually wants to be compliant, often for moral reasons but at least for audit purposes. If you make it hard to figure out what they are actually using (and will have to pay you for), they'll just start fighting you on everything and trying to game their way out of as many units as possible.

5) Ensure that the timing of pricing matches the provisioning of service. That's a fancy way of saying that if you are typical enterprise software vendor who will have an ongoing relationship with your customer for years, make sure that there is a good way to capture additional revenue down stream to make it continue to be worth supporting the customer.

Typically, enterprise software has a substantial maintenance and support charge that helps with this long term alignment. However, since this is allocated to the support and engineering organizations, it leaves nothing for the sales and service side to spend their effort working for.

SaaS models are ideally suited to this problem. The customer pays continuously as you provide your running software continuously.

However, even with conventional software 'sales', there are ways of generating recurring revenue. Just make sure that you have designed a product where the customer needs more over time. More seats, more transactions, more devices, more functions, etc.

6) Signal appropriately. Technically, this is probably more a price point issue but I'm throwing it in anyway. Make sure that the pricing is well aligned with your intended position in the market. If you are trying to be the high end vendor and go in with an pricing offer lower than your competitor you are not sending the right message.

7) Don't be too rigid. Enterprise software sales have a strong tendency to be customized for many of the customers. Either because they have unique needs, or more commonly because of competitive pressures and other negotiations.

Know and communicate to your team the healthy exception vectors. What things can be changed without violating best practices down the road? Price points are easy. Ratios of upfront to repeat charges (per time or per added unit) will fit into the model. However, changing the scalar metric to something you can't track is not a good idea.

If you've followed these best practices, the custom pricing should not cause problems rather just be another tool for generating business.

Where does your market data come from?

2009-01-07T01:01:00.000-08:00

In classic marketing classes, a lot of decisions are quantitatively driven or at least backed. If you've had that training and go into classic consumer marketing, you probably feel right at home.

However, in my experience, enterprise software marketing rarely has similar quantitative data available. This is particularly true in immature segments where you are creating the market. But it is even true in segments that are followed by industry analysts.

I've worked in some organizations where we commissioned our own research. But even there, the best data came from focus groups rather than statistical analysis.

So, if you don't have statistical or analytical data to work with, how do you get enough information to make good decisions? I believe that most often it comes from the ability to synthesize a number of often anecdotal bits of information into a cohesive whole. This is really the art of software product management and marketing.

Where does this information come from?

Customer themselves: This is the big one. We all go out and talk to our customers. Sometimes one to one, sometimes in bigger sessions. These interactions are good for a couple of types of input:

Major pain points for the customer. If they are all "whining" about the same thing, it should certainly be on the list
Topical issues. Like everyone else, customers will tend to feed you the top of mind stuff first. This can be a good trend indicator. But, be careful with this information as it might be old news by the time you do anything with it.
Innovative customers. If you have a few customers who clearly 'get' your product, work with them. These are the folks who might just give you the next great idea or at least the raw material for it.

Sales force: The sales team is often quite vocal about the topic of the day and very aware of things that are impacting competitiveness. However, they also tend to be even more short term focused than the customers. Be particularly wary of:

Only listening to the most vocal reps. The ones that seek you out may or may not be your best source. They may be the ones who are least successful at selling what you have and simply looking for excuses. The ones who know how to 'sell around' deficiencies or competitors' positioning are often the best and they are too busy to come to you.
Getting sucked into "last customer syndrome". This is where the answers you get are driven by whomever they talked to last. Part of your job is to extract more relevant trending information rather than just taking the one data point.

Make sure to include the Sales Engineers in your discussions with the field. Very often, they know more about the competitive situation than anyone because they were asked directly by customers to explain this or that and how it compares to 'brand x'.

Even more importantly, they know all the things they do in their demo setups to 'work around' the product. They may be making sales with demoware that should be in the product and you never know about it if you don't ask.

Support: You should be getting feedback from support not just on bug escalations but on things like 'top ten' lists of what customers call about, which they could do, have trouble with, etc. It's easy to get bogged down in the mechanics of processing and prioritizing escalations. But, while important, it isn't where the future lies. When your support team can tell you about how they just got the 20th call from customers trying to do "x" that they thought the product should do but doesn't, that isn't a hint, it's a club to the head if you listen.

Professional Services: Sadly, this is one of the most obvious in concept for enterprise software companies and in my experience almost never well executed. Your PS team is out there working closely with customers every day. Generally working on two kinds of things: 1) Deployments 2) Customizations. Might it be good to know what challenges they are having with the first, and what interesting ideas customers have for the second? Duck, that club is swinging at your head again.

Unfortunately, most of the time this information never crosses the organizational gap. PS folks are billed by the hour and aren't incented to spend time talking to you. Your engineering team will most likely have no interest in looking at the 'hack' work that the PS team has done for ideas.

Fixing this is hard. But you can do your best. Work with the PS team management to identify top issues lists during deployments. Figure out how much time or customer satisfaction are being squandered. Create a process for at least tracking and sharing the summary of customization products. Maybe even make a PM/Dev review part of the process for bigger ones.

Industry analysts: If you have them, this is obviously a great source. The good ones will bring you new ideas synthesized from their conversations with multiple customers. But be careful. If you pull too much and don't end up doing it, it is worse than when you let a customer think you'll have a new feature by year end because the analysts have communication leverage.

Build a good relationship with the analysts that cover your space. They should be treated as your friend, even if you need to keep them at arms length sometimes. Once you have reasonably well baked ideas, they can be great validation points as long as you understand their personal interests and biases. No point in pitching your great new app for Market A to the analyst who just published a piece on how Market A is a waste of time. (BTW, do have a good argument to yourself and your management about why it isn't?). By the same token, if you heard them say that a "42 inch Widget" would be the best thing if only someone built it and you have finally come to the same conclusion, they are great people to see if the "Super WonderWidget" hits the mark.

Engineers: Last but not least, is your own engineering team. If you've got a good team, they should have domain knowledge themselves on what would be interesting to customers. Make a point to take them along on the customer visits so they can be part of the 'brain trust' that really understands what makes sense. By the same token, this lets them build features better the first time. They'll really understand how customers want to look at things and you'll go through fewer design revisions.

However, do be careful about the balance of power issues. PM and Dev should be great partners but you are still responsible for driving the product direction. You don't want to let things go down the slippery slope to uncontrolled releases that are driven by the engineering team's desires rather than market needs. At the end of the day, all of these inputs need to by synthesized into a cohesive roadmap and product plan by you.

New Rules?

2009-01-06T13:27:00.000-08:00

I got started on this as a response to a post at On Product Management talking about the "New Rules of (almost) Everything" and realized it needed (or maybe I needed) more than a comment should be. Please go read the whole post too, but I'll highlight the rules here:

The New Rules? Same as the Old Old Rules.

Solve a problem that really causes problems for people. Simply being cool isn’t enough.
Figure out how to make people do what they need to do easier or quicker or cheaper.
Help them do something new that they couldn’t do before, but always wanted to do.
Understand the value you deliver and communicate it to them clearly and simply.
Charge a fair price for the innovation and build a scalable business around it.
Hire smart people to help you because you don’t have all the answers.
Teams of smart people have the best chance of finding creative solutions to new problems.
Don’t forget that the next economic downturn will come way sooner than you expect so prepare for it when times are good.

I really like the “New Rules” because they focus on the basics of building a business (whether a startup or a product line). I think that we are exiting a second period in less than a decade where the tech industry forgot a couple of these basics.

#4 with #1: both in the Dot Com bubble and surprisingly often in the Web 2.0 wave, people are building businesses around cool stuff where they ADMIT to not knowing how to make any money off of it. This ties in directly with #5 in designing the scalable business from the front.

I’ll admit that there are two cases that look bad but can be ok: 1) A business that needs to go viral to succeed. Fine, go in cheap to get the business. 2) A true research project functioning as an incubator.

However, in both cases it is irresponsible to not at least have a theory of how to make money on it. It might not play that way in the end but without thinking about it up front, the only exit is to sell it to the “greater fool”. (Then again, there are a lot of those, aren’t there)

I even read a job posting for a company company looking for a head of Product Management for Monetization (they were looking for somebody to figure out how to add features that would make some money), I have to wonder what people are thinking.

At the end of the day the 'new rules' are the same as they've always been: Do something that people want enough to pay you enough to make a living. If you can't figure out how your favorite gizmo would be worth what it will cost you to make it, you'll never succeed.

Do I care about SaaS, Multi-tenancy, Hosted solutions, "whachamacallit"?

2008-12-30T22:52:00.000-08:00

Ok, here we go with buzzword bingo. If you are in the software product space at all and you aren't thinking about SaaS, Hosted/ASP Solutions, Multi-tenant solutions, cloud deployments etc. you are likely making a big mistake.

Note: I am fully aware that these terms are not synonyms, but they have a lot of overlapping issues in regards to product strategy so I am using them interchangeably in this context. If you don't know the difference, go read up. And you 'dot com' and cloud folks can probably ignore this whole post. This is aimed at classic enterprise software folks who need to shift gears.

I'm not trying to argue that all software should be deployed and marketed in one or all of these ways. I do still believe that there is, and will continue to be, a solid market for traditionally licensed and deployed software on both the enterprise and PC side.

However, solutions "in the cloud" are here to stay and will grow in relevancy. If you are not at least considering them for your enterprise software product you aren't doing your job.

A few reasons to be considering it

Revenue models: Can you say "annuity stream"? Makes maintenance revenue look sad. Of course it is challenging to forfeit the up front cash of license sales if the business has been built around it. But if it can be managed (or if it was never there), hosted solutions look really good in succeeding years.
Reduced market friction, Increased adoption rate: Hosted solutions can make it easier for a business user to start using your application. No need to justify the large capital expense, engage IT etc. This helps you accelerate your growth.
Scale: From the customer's perspective, a hosted solution can generally be scaled rapidly and infinitely. There is significantly less need for complex, long term IT planning to ensure availability of the service.
Update cycles: In classic enterprise software, the vendor releases regular updates which enhance and improve the product. However, most customers don't adopt each and every update for expense, logistical, training and other reasons. As such, they don't maximize the advantage from the maintenance money they are spending. In contrast, hosted solutions are generally updated for them immediately thus yielding benefit to the customer immediately.
Functionality: Now for the most intriguing one. Hosted solutions can do things differently that might be game changers in the market. Think collaboration or community functions. For example, no longer must baseline data come from a single customer instance.

Objections to consider

Doesn't address a buying objection in the market. This is a big one. If your prospects don't have any interest in the merits of a hosted solution, this may not be for you. However, understand it well. You may very reasonably conclude that the infrastructure costs/hassles of a traditional deployment are not significant to your customers. You might even want that as part of a lock-in with the organization. But, you might be missing an opportunity to reduce friction in the adoption cycle particularly in these financially challenged times.

Perceived need for data 'ownership'. This is often one of the biggest ones. How can your customer be expected to trust you with the customer data, patient data, financial data, whatever. You aren't under their control. Blah blah blah. In my opinion, for all but defense security applications, this one is really just a ruse of inertia. Here's the reality: 1) By buying your software, particularly web UI software made available to customers, suppliers etc., they are already depending on your good security design to protect their proprietary information. 2) If your company is good at its job, you should be able to be at least as good at administrating and securing the information as their in-house IT. In fact you might be more secure because you will get more independent oversight. 3) There are ways to design in backup and data retention in such a way that your customers can trust that they will still be able to access data if you fail in some way.

Factors to consider

Operational readiness: Running a SaaS or hosted business isn't just a matter of spinning up your software and signing up customers. The business has to be ready to define and deliver on the service levels that customers expect. This requires additional staffing, processes and infrastructure far beyond the normal IT needs.
Technology: Is your application built on a technology stack that is easily deployed in the cloud or other dynamically scalable infrastructure? If not, hosting options will probably end up costing a lot to actually run as you spin up wholly separate instances for each customer.
Architecture: This is where multitenancy comes to the fore. A hosted application needs to be designed from the start to support multiple, segregated data sets for each customer. There are multiple ways to do this, but it is quite hard to retrofit in a cost effective manner. (see this MSDN article for a detailed overview)
Business models: I alluded to this above but this is one of the biggest issues. Can your business sustain itself on deferred revenue? The nirvana of ongoing revenue streams is pointless if you run out of cash.

Do I really need a business case?

2008-12-29T20:02:00.000-08:00

The level of process maturity varies greatly from one company to another. Some organizations need to have all steps followed and documented. Meanwhile, others have more flexible processes where only some steps are followed some times.

In these environments one of the temptations I have often observed is to skip a real business case. However, I would argue that this is a huge mistake.

The two most common situation where the business case is skipped are:

'Minor releases' where the development teams feel they have a solid handle on the tasks to be done. In such a situation it is tempting to skip the business case in favor of just doing what "everyone" knows is the "right thing" or by relying on the expertise of the product manager.
Executive driven projects where the framework has come down from the the Sr. Execs. Since it is just presumed that it will be done, nobody builds the formal business case.

However, skipping the business case step is a lot like the problem of an unfocused release. While it often works under 'normal' circumstances, it too fails when the allocation of resources, content or schedule comes under fire. Gee, will those same execs remember the justification used when the doo doo hits the fan later?

What the business case does for the process is provide an agreed-upon framework for evaluating the merits of the project. In the business case, you can identify the potential benefits as well as planned costs to achieve those benefits. These can be quantitative but they can also be qualitative, particularly for strategic or competitive efforts. With these objectives clearly documented, the other decisions fall into place and it is easier to 'rally the troops' around the 'right thing' to do.

Pick one thing (well, maybe 3)

2008-12-23T00:47:00.001-08:00

Product managers have a great temptation to try to assemble a broad list of features for a release that maximally uses the resources, time or both. While this 'kitchen sink strategizing' might seem efficient on one level in that it gets as many things done as possible, it fails on two very important ones.

Failure One

First, it isn't a sign of strategic thinking and won't achieve strategic objectives. How could it, you aren't setting any!

These laundry list features are classic for 4.x or 5.y kind of releases where the product is generally mature but a gazillion customers have been beating down the door to get their favorite feature adopted. They aren't good there and with immature products they are a real disaster.

Either way, you are squandering your resources and time on features that:

won't bring in more customers/segments
won't get more revenue from existing customers/segments
(and this one is really scary) won't advance your position against your competition

Failure Two

Secondly, it doesn't drive the project. Nobody gets excited about laundry list releases except the people who asked for one of the items. Of course, they probably have another one you didn't get in so they'll be annoyed that something else took precedence over their pet.

More importantly, it is difficult to get exectutive and organizational support. People can't latch on to the theme and stand behind it everywhere they go. Developers, won't understand what's really important. Marketing and sales people won't be able to explain the vision to customers and so on.

Now for the real fun. What happens if resources get cut or the schedule changes? You've got no built in groundswell for the project. Random things will have to be cut to make it work. In fact the whole project might get dumped. You might have a sense of which items on the list were of the most long term relevance, but since you didn't get buy-in to that strategy up front, good luck making the case under duress.

The Solution

So, what to do? The title of this post should give you a hint. Pick one theme to build a release around. In big projects you might even pick a second or third lesser themes to go along with the primary. But this focus is necessary.

This key theme can then be the driver for a business case for the project. It also forms the foundation for the message tree for later communiction (see "Write the Press Release..."). It gives the team and overall organization a goal to focus on.

You might be wondering "so how do I ever get those important but non-strategic thing done?" My argument here isn't that it's not possible to have a lengthy list of smaller features in a decent size project. Merely that there must be a key theme (or three) and clear prioritization. I find the MHW system for prioritization very effective here. The key theme items are all "Musts". "Hopefully" can capture those that are the most closely aligned with the key theme. "Wish" is for everything else and this includes customer pet features. (If it was really that important maybe it should have been a theme?)

Resource Content Schedule: Remedial Project Planning

2008-12-22T20:22:00.000-08:00

Sometimes it is worth reviewing the basics. I was listening to a fellow product manager recently who was complaining how they couldn't ever lock plans and deliver as expected because things always change. This is not good management. Sure things can change, but it must be done in context and intentionally.

At the end of the day, the scope of all development projects come down to a basic function:

Project scope is a function of Resources, Content, and Schedule

Resources: The people and equipment deployed on the project
Content: The features expected in the finished project
Schedule: The time allocated in terms of working units (hours/days/weeks) or calendar time

You could probably get fancy with a formula that added constants and factors to derive a true equation and the relative weights of each factor but it really all comes down to one dynamic: Projects with a chance of measurable success have a finite scope, changing one variable requires changing another. If you add Content you have to either increase Resources or Schedule. Similarly reducing Schedule requires cutting Content or increasing Resources.

These are what some people call 'laws of physics' problems. They could just as easily be called 'laws of projects'. There is no magic, just effective tradeoffs.

So, the next time someone wants "just one more feature" or to "borrow a developer" go back to basics. Ask what s/he'd like to change? Delay the project? Lend extra resources later? Cut something else from the feature list? Something must be done.

"Internationalization", "I18N", whatever. It's just good planning

2008-12-21T22:51:00.000-08:00

Ok, this one is a pet peave of mine, I'll admit it. First a quick bit a definition:

Internationalization (I18N in some geeky circles): This is the design of software to be able to operate in a global context. This includes things like:

Not hard coding text strings into functions. Better yet, storing them in an external file at least at the source level.
Ensuring that other character code pages will work. Unicode has complexity tradeoffs sometimes but at least support all of the normal western 'funky' characters like umlauts and tildes etc.
Allowing numbers and dates to be stored and calculated independently from the display format. Quick, how much is "342.098" in Germany? (It is three hundred thousand something) When is 5.12.08 in much of the world? (It isn't last May)

Localiation (L10N in the same cirles): This is actually doing the hard (i.e. costly) work of making the software look local to the user.

Translating the text strings to another language
Translating help files and documents
Changing or adding features to represent the use models in another country (i.e. VAT taxes instead of sales taxes)

Now the simple advice: Just do it now. You can leave the more expensive localization work for later but design for internationalization from the beginning.

In my opinion, not internationalizing software from the get go is a dumb, amateurish, mistake with very few exceptions. Sure, if you are writing software to sell only to Wisconsin farmers, you might not ever have a reason to need it. But for nearly all enterprise and consumer software and even most consumer web sites, eventually you will want to sell it in some other country (even neighborly Canada expects French and English for public apps) or even to an ESL market here in the US.

"Well, I can just take care of it then" No, you don't want to do that.

It will forever be the 'fourth thing' on your priority list where only the top three get done.
Doing it later costs WAY more in time and resources. If you try to do it years down the road, the developers who hard coded the obscure bits of functionality are long gone and the new guys will spend forever debugging it and eventually re-writing huge portions. We aren't talking about XP programming revs here but reworked whole releases for no visible gain to the customers. Yikes.
It will seem too expensive and not seem like a good bet. Beyond the cost issues in #2 above, you will often find a chicken and egg problem. It's so expensive to do, management needs to see revenue to justify it. But, because it doesn't work in that market you don't have any market growth to point at as a clear justification. Use as an educated guess that it will cost you an extra 5% to do it up front. But it could burn an entire release cycle to 'fix' things later.

Are you convinced yet? No? Ok, let me throw the last pitch: If you don't, you'll look like a dummy.

When your competitor launches in 10 new markets and your colleagues want to know why you aren't doing it, do you want to tell them that it will cost 6 months of pain to enable it?
Take a look at nearly all software written outside the USA. Rarely will you see mono-location designs. This will make it hard for you to get a foothold even with the bleeding edge customers who will tolerate English language software for a while to get the cool features you have.

Write the press release before the code (or anything else)

2008-12-18T15:44:00.000-08:00

What? Why should I write the press release before I've done anything else? That makes no sense. I don't know what we're going to do in the release.

That's exactly the point. If you think about the PR that will eventually be written for the release, it will help you and the team focus on what is sell able and really matters.

Think like a writer. Come up with a main point (feature or benefit) and perhaps a couple of supporting points and write it up. This will end up exciting the team (including executive management) about the project far more than a feature list spreadsheet of 273 rows that lists everything in priority order. Of course, you need that too, but having the pitch down will help everyone align on the priorities.

(Disclaimer: I 'stole' this one from a CEO who kept asking for the PR in planning sessions for this very reason)

System for prioritization of features

2008-12-11T01:03:00.000-08:00

I know, everybody has some magic formula for setting up prioritizations in their product plans, MRDs, PRDs, Go-to-market plans etc. However, I have found most of them overly complex. This leads to more argument about what each tier really means than it is worth.

Years ago at Remedy I learned a simple system that is supposed to have come from HP. It is simple and effective. Since we all like acronyms in this industry, let's just call it the "MHW" system.

M

"M" stands for "Must". This means that this feature, action, etc. MUST be in the release in order to proceed. These are the things that support the key objectives and messages of the release and should only be skipped if the whole project has been re-prioritized.

H

H is for "Hopefully" as in "hopefully this will make it in". And as Rick Page says "Hope is not a strategy". However, that isn't what this means. It means that the feature is budgeted for the project in terms of time and resources. However, it can be dropped if schedule or change in resources demands it.

W

"Wish" is sometimes the trickiest one to understand. A 'wish' feature is often on the plan simply because it is tied in some way to other things in the project. For example, you've always wanted to change the way Module X works but it just hasn't made the priorty cut. However, there will be other things done to Module X in this project so the developers should be aware of the improvement that could be done if it is efficient. Most of the time Wish items don't make it but it still is a usefull communication tool.

The beauty of this system is that it is simple and concrete at the same time. Anybody who wants to change a Must understands that this will require changing the vision of the whole project. Having hopefullies budgeted gives them a reasonable chance of being done but also gives the development team some 'wiggle room' in the project plan. And wishes are just about communication.

As a rough guideline, Must items should make up 50%-75% of the project because these are the things that the team has to agree is worth spending resources to get done. Having Hopefullies gives some buffer to make schedule but having too many makes the project outcome too vague.

Competitive intelligence and strategy

2008-12-10T23:26:00.000-08:00

Product Managers and Marketers spend a meaningful amount of time doing competitive research and planning strategies to be successful in the competitive market. While time will often prove the merits of such strategies, one of the most interesting opportunities is when you end up merging with a competitor and can trade notes. You may both be off a bit but the comparison itself is usually enlightening. I'll share one example to start off:

Assumptions are critical to game theory and strategy

In one situation, I was working for a start up in a young industry. There were a very limited number of direct competitors so we watched each other's behavior very closely when we could. However, because of the small nature of the market, there was very little third party information available to corroborate any perceptions that were formed.

We observed our competitor routinely "diving for the bottom" in competitive bids. They would come in hard and low on pricing, radically undercutting our (and their) standard pricing, "giving away" extras just to win the deal.

We looked at this situation and assumed that they were nuts. While this is an often tempting assumption about "the other guys" it is rarely a good one in the cold light of day. We held our own pricing as high as possible in the interest of "preserving the market" for the future.

Our assumption was that the market was big enough for both of us and that it was important to not contaminate the pricing models to the point where we'd both be unprofitable in the long run.

We were actually reasonably successful in convincing customers that our behavior was that of a rational, long-term-viable vendor and theirs wasn't.

The problem was that our assumptions were flawed in respect to our competition. They thought that only one of us could survive. Thus, it was perfectly rational to try to outlast us "at the bottom" because there would only be one victor anyway.

Thus, all of our well intentioned market signaling was pointless. We just didn't get it. After the second round of this "self destructive" behavior in a year, we should have re-examined our assumptions and adjusted strategy accordingly.

As it turned out, their assumption about the market potential may or may not have been right. However, they were able to "drown" us at the bottom while they survived on bigger cash supplies.

Welcome!

2008-12-10T23:18:00.001-08:00

Having recently gone through yet another acquisition and the resulting changes, I got to thinking about what it is that draws me to product management and marketing and what things I've learned through experience (i.e. the hard way). I figured that it might be time for me to start blogging to share this information.

I don't think that I know everything there is to know by any means so I'm really hoping that I end up with an audience that will comment and argue over the various posts here. Please consider this an open invitation. Any respectful, on-topic opinion is welcome.

One of the other things that this project is getting me to do is look around the web to see what other people have done in a similar vein. I will put interesting links in posts and/or in the sidebar to share. Please feel free to add your favorites to your comments as well.

Like all blogs, this will start out thin. If you're joining the conversation then, please come back again or add something yourself.