A simple exercise for pricing new products

In most of my product management experience, I have been spared much of the difficult work of defining my products' pricing model. The truth is, in big shops like IBM and Microsoft, there are dedicated professionals who have forgotten more about pricing than most of us will ever know; they are the ones that set the price (often against the complex backdrop of a huge, multi-faceted portfolio and opaque strategy). However, with smaller companies and startups, pricing can be a very difficult exercise that can easily take on the feel of "Voodoo Economics".

If you're product competes in a mature market, pricing is often fairly straightforward as your competitors and industry norms and history provide some guidance. In these instances, disruptive business models that change the pricing model can be fertile ground for innovating and avoiding simple (margin-sapping) price-wars.

If you're in a new market or even one that you're creating (the kind of "Blue Ocean" opportunity we should all be pursuing), defining a pricing model (metric, price point and discount schedule) can be daunting. In this post, I'll propose a simple practice that can provide some guidance, primarily in the B2B world where products must be positioned with prospects by sales professionals (solutions addressing complex problem spaces rarely go viral!).

In the case of complex B2B sales, a great way to stimulate creative thinking on pricing is to work backward from the sales pitch. I know this sounds obvious, but this approach is often overlooked. By definition, complex sales involve multiple decision-makers and influencers. There is a high probability that beginning with the first pitch, sales professionals will have to gradually refine a business case that begins with a concise expression of value. A crude example would be "Our product will save you around X Euros/Dollars/Won per year but only costs [some fraction of X]". In practice, the value proposition of many products isn't so clear, i.e., reducible to a obvious monetary value. Regardless, this type of logic will almost inevitably be employed.

To draft this pitch you should enlist the help of a sales professional. Before you do that though, you need to have dissected and decomposed the mythical entity known as "the customer". The truth is, when an organization buys your product, there are many stakeholders that, by definition, impact the sale: the economic buyer, influencers, end users, administrators etc. You need to understand each of these constituencies and have a solid idea (later to be validated with them) about "what's in it for them" relative to your product. Armed with these hypothesis and an intimate understanding of your product, you are now ready to speak directly with a customer-facing sales professional to draft a high-level pitch. In my experience, it won't take them long to identify the pricing messages and positioning they think will resonate with prospective customers.

Once you've elaborated the pitch a bit, you (with the help of sales, ideally) should do some direct validation with folks in your target market(s). Your goal is to find out if you understand their perception of value and which messages are most convincing. The variables in the equation can be tricky to determine, but its basic structure is simple: our product can generate a value of X but will only cost you some fraction of that amount. If you have close relationships with some members of your target market (clearly the right goal), you can begin analyzing what metric works for them, e.g., per processor, enterprise-level, and get their reaction to your proposed price point.

Coal Chutes in Your Software Product

I live in Heidelberg, Germany, an "old" city (since the 5th century!) that wears many of its "wrinkles" with pride. Plenty of old buildings in the oldest part of town have coal chutes that were used years ago to deliver fuel for long defunct heating systems. Staring at one of these anachronistic mechanisms as I write this, I've begun thinking about how many things that were once an absolute necessity are now obsolete. What can software product managers learn from these quaint reminders of a bygone era?

1. As your product evolves, the value of many of its critical features will erode

Keeping yourself aware of your product as a whole rather than focusing on its newest, most exciting features will help you identify its "coal chutes". Paying attention to trends in users' needs and habits can help make you aware of the darker corners of the product that are collecting cobwebs. Having statistics related to users' habits can provide critical data in this respect.

2. It's impossible to foresee all the features that will become obsolete, but that doesn't excuse you from thinking about them

As you design your product, ask yourself what assumptions you're making about what users need and how they accomplish their goals. Revisit these assumptions regularly to identify those that have been invalidated and begin planning the best ways to address these changes.

3. Sometimes out-of-date features represent threats

Just as some nefarious types will use an old coal chute as a point of entry for questionable activities inside of the building, your out-of-date features may provide unforeseen access points to your product or at the very least least project an image that isn't consistent with your product's current value proposition. Think seriously about the threats these old features represent and the cost of continuously mitigating them. Sometimes "bricking them in" or removing them all together is  a wise choice. These "remodels" may be expensive but can pay off in the long run.

So what do you think? Does your product have a coal chute or two that require some of your attention? Are you aware of the assumptions that underlie your products features and functions, including its UX? What is your plan to deal with them?

Agile development isn't enough

I was talking to a board member of a mid-size company a few weeks back about his biggest challenges. After over a year of struggle implementing Agile and changing a couple of products to be delivered as services (SaaS), one of his biggest pains was keeping marketing, sales and support up to speed as the release rhythm accelerated. After asking him a couple of questions regarding how product management engaged with these "functions" (luckily, he has an effective, empowered product management team), it became apparent to me that while PM and development had made great progress with respect to adopting Scrum, the other functions had been left behind!

On the surface, it seems obvious that if development is delivering releases at a higher frequency, sale's needs are going to change with respect to enablement and demos, for example; marketing's needs are going to change in a similar fashion. The same can be said about support, who moves from a model of "handover" a couple of times a year to continuously absorbing new changes, including new problems. Put simply, if you want to realize the benefits of Agile/Scrum or Lean or SaaS, the entire "train" will have to get on the track. That means frequent, managed engagement with all internal stakeholders, including IT. On that note, DevOps is the area that I see the most conspicuous acknowledgement of the need for the entire extended product team to adapt to new development approaches and techniques.

The days of waterfall development taught us that pulling in sales and marketing toward the end of the release is a mistake. These problems are exacerbated when release rhythm picks up. The answer? Creating continuous, efficient engagement with all stakeholders; it is probably the most important step you can take to ensure alignment, effective collaboration and maximum "throughput" end-to-end. The importance of making sure the leadership of these organizations understands what the change in development approach and product delivery means to them cannot be overstated.

What's your experience? Have you seen organizations that have gotten development on the Agile track but have left other parts of the organization behind?

Previous post: Balancing Release Investments with Simple Analytics

You can find more information about me (including upcoming training dates) at www.prickril.com.

Balancing Release Investments with Simple Analytics

This post by Rich Mironov resonated with me even more than usual (if you don't regularly read his stuff, you should!). Rich describes a practice involving placing completed user stories in the following buckets to get insight on how you're really spending your development dollars (and thus getting insight into your strategy, even if it's implicit):

·        Planned features

·        Unplanned features

·        Quality and development infrastructure

·        Longer-term research

Rich's post reminded me of a similar practice I've had of categorizing proposed investments in a release. He's right on with the a pie chart or similar graphic being much more useful in communicating the insights gained.

Before I describe my practice, I have to be forthright about how I've typically done release planning during most of career. Because I've worked at big/huge primarily B2B shops with (probably) overdeveloped portfolio processes, we were always forced to consider the likely scope of a given release long before we started development. While such a practice is clearly not in vogue in a software development world dominated by Agile/Lean thinking, because of intra-portfolio dependencies, expectations of big customers (some of the biggest companies in the world) and staunch competition for development resources, we simply couldn't tell our stakeholders "We can't tell you yet what we'll deliver". In my experience in these big shops, Agile/Scrum was used as a mechanism to allow deviation from these plans as necessary, but didn't preclude our defining our intentions relative to a release before we began building it.

BTW, Rich's approach suggests calculating story points for completed stories/features/epics to determine proportional investment. In terms of release planning, our metric was always development capacity expressed as person-days, one of the key goals of release planning being to convince ourselves that we had a reasonable fit between planned investments and available development capacity (and setting the stage for requesting additional resources as needed).

Here are a few interesting pivots that I would assume could  drive insight into investments we've already made (or "implicit strategy" to use Rich's terminology) as well as planned investments. Once again, I realize people who have drunk deeply from the Agile Kook-aid pitcher will balk at the idea of this level of detailed planning before development begins, but, what can I say? It's an imperfect world and we were doing the best we could in sometimes very un-Agile organizations.

Kano model

The Kano model was the original inspiration for generating simple analytics based on investment categorization. We had launched a new product that had barely made it out the door. Suffice it to say none of us were thrilled with the final scope nor the level of quality. At "power vendors", the truth is that it is assumed that you'll get it "right" on the third release, but that's fodder for another post. Anyway, as we planned the next release, we quickly realized that just fixing perceived gaps and addressing very real quality issues would consume all development capacity. When we considered the press release for V2, we realized we had virtually nothing in the release to generate excitement.

This quick exercise can help you determine if your release has enough sizzle to get customers' and analysts' attention when you launch.

Customers we have vs. customers we want

Another way to categorize investments involves considering if the investment is likely to please the customer segments you have or represents an investment to acquire customers in new segments. Although the line isn't always clear, try categorizing your investments based on who you think they'll most resonate with:

·        Existing Segments

·        New Segments

·        Both

·        Indifferent (overcoming technical debt etc.)

Products at the beginning and end of their life cycles often must attract new customer segments, often with features that may not be particularly valuable to their installed base. If you're not investing in attracting new customer segments, ask yourself why not. This categorization also gives you insight into to proportion of your investment that is going toward things that please no customer whatsoever. I've been involved in releases when this "bucket" consumed 80% or more of our development calories.

Stakeholders

Categorizing your investments by stakeholder can also be an interesting exercise. While it's natural to focus on customers, the truth is that we product managers must often please multiple masters. Here are some typical stakeholder categories:

·        Customers (consider decomposing this one based on segments as well)

·        Partners

·        Management (investment in quality initiatives, portfolio interoperability etc.)

·        Product standards compliance(accessibility, supportability etc.)

·        Sales (to close some critical deals, for example)

This exercise should also make it fairly easy to see how much of your investment is intended to please internal vs. external stakeholders (in big shops, you internal stakeholders my consume a significant number of calories).

Conclusion

So there you have it, a few ways to categorize investments you intend to make to get insight into priorities and possibly make adjustments before development starts. Do you do similar categorization?

You can find more information about me (including upcoming training dates) at www.prickril.com.

Product Manager: You Are a Keystone

I have an overview presentation on product management that I've been refining for years. One of the most interesting slides is entitled "Why product management is hard". Reviewing the slide recently, a theme emerged that I had considered previously but I hadn't thought about deeply: one of the key sources of complexity and confusion for product managers and those who must work with them is the fact that product management spans so many boundaries that are much clearer for other professionals. While I often refer this delicate situation as "bridging" different worlds, I now prefer the analogy of a keystone. In case you're not familiar with the term, a keystone is "a central stone at the summit of an arch, locking the whole together." I like the idea that the keystone sits between two opposing forces, making the entire structure stronger. In this post, I'd like to enumerate some of the ways that a product manager acts as a keystone.

Product managers are a keystone between:

The Functional and Technical Perspectives

In a previous post, I described how the "outside in" functional perspective, which defines the "why" and "what" of a product, is fundamentally different from the "inside out" technical perspective, which defines "how" something gets built. Even though product management accountabilities are functional, in highly technology-oriented domains such as software product management, it is important (if not critical) for PMs to have technical knowledge relevant to their domain and to understand how software is built and tested. Bridging these worlds can be difficult as technology changes rapidly and too much familiarity can constrain what a product manager perceives as possible.

The Problem and Solution Spaces

I've also written about the problem and solution spaces and the product manager's relationship to them. If you read this blog, you know that I think a thorough understanding of the problem space is absolutely critical for product managers. In terms of our relationship to the solution space, you need look no further than our title! We *are not* problem managers; we are product managers! As a product manager, you must identify a compelling market problem and address it with a solution that will generate expected business results.

"On the shelf" and "off the shelf" Professionals

I've previously used the analogy of a shelf as a simple model to demonstrate the traditional accountabilities of a product owner. In my experience, product managers are primarily responsible for getting the right product "on the shelf", or available to the market at the right time at the right cost. Marketing and sales are more often accountable for getting the product "off the shelf". As a product manager, we are often in a unique position to keep these worlds communicating and aligned. I typically use "business reviews" as an opportunity to bring the "on the shelf" and "off the shelf" folks together. I'll write a bit more about this practice in a future post.

Outside the Firewall and Inside the Firewall

Although all members of the product development team should be exposed directly to the "outside world" (including customers), there's no denying that the product manager plays a special role in brokering this communication and making sure each "side" is aligned and in balance. Regularly sharing your experiences with customers and partners is a great way to increase your credibility with engineering and keep them in the loop. Taking a developer or quality professional with you on customer visits from time to time can make development feel more involved and improve your relationship with technicians in general.

Product strategy definition and execution

As a product manager, you're not only accountable for defining your product's vision and strategy (with the help of others, of course!), but you're responsible for making sure it gets executed! On the definition side, you should be working closely with executive leadership and other disciplines to define the right vision and a plan for achieving it. On the execution side, you should be making sure you're doing something strategic every day and "orchestrating" the efforts of others to execute your plan.

Would you agree with my assessment? Are there other "keystone" roles that product managers play?

See more information on me (including upcoming training dates) at www.prickril.com.

Strategic Software Product Management (SPM) White Paper

I've just finished a white paper on the strategic role of software product management in software product organizations. You can register for a free copy on my site, www.prickril.com. Looking forward to hearing your feedback!

What product managers need BEFORE they prioritize release investments

The fact that I see lots of blog posts and other content on feature prioritization makes sense -- it's generally considered one of the key accountabilities of product managers. There are all kinds of prioritization techniques, e.g., value vs. complexity, the Kano Model and MoSCoW,  that can help you focus on investments that are most likely to contribute to your product's success. Recently, I realized that I see much less emphasis placed on the preparation required to prioritize features, irrespective of the approach adopted. It also occurred to me that very often product managers are prioritizing the wrong things.

It is common for product managers to create lists of requirements or the associated features (requirements and features are *not* the same thing) and then try to prioritize or even stack rank them based on a combination of intuition and perhaps one or more of the prioritization techniques mentioned above. The problem with this approach is that individual features, by themselves, don't necessarily support a broader use case or scenario that actually delivers customer value. Imagine someone asking you as a car buyer if you prefer a stereo in the car *or* speakers. The truth is, your requirement is that you can listen to music. I was years into my career before I realized that I should be prioritizing use cases/scenarios rather than individual features. I must admit I'm a bit embarrassed that I regularly provided customers and partners with flat lists of features and asked them to prioritize them (sometimes based on a fake budget) without their having an understanding of how these features would work together to support their key scenarios. I realize now the results from such exercises were extremely suspect and often misleading.

So now that we know what to prioritize (use cases/user stories scanrios and not features), what do we need as input for the prioritization exercise regardless of the method we plan to use? I would suggest the following:

Business Motivation
Here I refer to the "why"aspect of product development, referring specifically to the OMG's Business Motivation Model, which defines key concepts such as vision, goals and objectives. Defining a product can be thought of as an exercise is balancing stakeholder needs with your product vision, which, if you desire to be innovative, will, by definition, imply investments in features your customers don't know they want yet! Understanding your vision and business objectives clearly is critical to prioritizing investments in your product.  I've written about the business motivation model in a previous post.

Stakeholder Analysis
The use cases or scenarios you're prioritizing should be a reflection of requirements you've gathered from all your stakeholders, including (but not limited to!) customers. Partners, executive management and even product managers of other products in the portfolio can have a profound impact on your product's success; don't overlook them! If you're not aware of all of your stakeholders or don't understand their influence on your product's success, there is a very good chance your prioritization efforts will yield half-baked results and ultimately, unhappy stakeholders. The stakeholder influence-impact grid can be a great start to understanding your stakeholders.

Implementation Estimates
You will need at least high level estimates of how much effort each use case will take to develop and test (development costs can be dwarfed by the cost of testing some features). It is impossible to reason over the net benefit of a given investment if you don't understand the cost side of the equation. Although accurate estimates can be hard to come by early in the release process, techniques such as t-shirt sizing can help.

Business Justification
Each user scenario you prioritize should be justified from a business perspective. I'm not referring here to a full-fledged business case, which can be difficult or impossible to reasonably develop at the feature level. What I mean is that you should have a sense of the likely business impact with enough detail that you can compare scenarios on this basis. Will the scenario increase adoption? Will it unblock a significant number of sales? Doing some thinking here can help exclude features that seem valuable but have questionable business impact and, of course, help determine which scenarios will give you the best bang for your buck.

What do you do to prepare for prioritizing release investments? What other types of data do you collect? What exactly do you prioritize?

Previous post: A simple life hack to deal with the mental "reminders" we receive on the verge of sleep

You can find more information about me (including upcoming training dates) at www.prickril.com.