Product Management
Four Artifacts to Define a Sellable Product
Jul 31st
Recent work on business plans and business cases refocused me on the need to document for a wide audience the purpose and design of a product, within the context of how it would be delivered to market and how it would prove profitable. As I reflected upon this, it occurred to me that a concise package could be assembled that delivers all the information needed to evaluate a product.
I’m sure someone has thought of this before, and there’s probably a formal name for it, but I thought I’d document it while it’s in my head….and before I delete the email in which I decided to capture it.
1) What Problem is Being Solved: The overarching product summary should start with a definition of the problem(s) being solved. From this definition, anyone reading this package can evaluate whether the proposed solution addresses the problem or problems stated. Much expense can be saved by not delivering a solution to market that doesn’t address the intended problem.
2) Buyer and User Personas: Who is the primary user for whom a product is to be built, and who is the buyer actually responsible for the decision to purchase? Often times these are not the same people–a proper user persona can identify the user’s tendencies and the typical person who will be using the product, whereas a buyer persona can help to keep the buyer’s motivations in mind.
3) Value Proposition: A succinct explanation of how the product can provide tangible, financial benefit to the user. One method is to show the value of the time saved by elimination of manual steps, which can show the value of efficiency. Increased revenue may be harder to validate, but using reasonable estimates can help to show the exact amount of value that a user will obtain by using the product. This evaluation is helpful when it comes to pricing the product for the market, and should take into account how the solution solves the stated problem for the buyer and users defined above.
4) Solution Workflows: For a software product, no presentation of the proposed product is complete without a robust set of wireframes weaved together with a good story. Packaging this all together helps answer “what are we building, exactly?” and helps build the case that the solution proposed is indeed the best one, for the conditions in items one and two above.
There are other items packaged in a business case — in particular, one that comes to mind is a pricing proposal — but the items listed here are enough to deliver to business people within a large software company to make the case that a particular product is solving a real market need for real users, and to explain exactly what product is proposed to meet that need.
Book Review: Tuned In by Craig Stull, Phil Myers and David Meerman Scott
Jan 4th
Product managers are the jacks-of-all-trades living behind the great and the ordinary products all around us. They are in charge of the product’s position in the market, its features, and ultimately its profitability. One of the biggest challenges is crafting a product that truly strikes a chord with an audience, immediately feeling comfortable. The authors of Tuned In: Uncover the Extraordinary Opportunities That Lead to Business Breakthroughs describe a six-step process for creating a products that do just that, using several case studies as well as personal experience to illustrate their points.
The six step process is as follows:
1. Find unresolved problems
2. Understand buyer personas
3. Quantify the impact
4. Create breakthrough experiences
5. Articulate powerful ideas
6. Establish authentic connections
The authors are thought leaders with Pragmatic Marketing, a highly-regarded consultancy in the world of product management. They teach a proprietary framework of 37 elements of product management which at a high level describes the process of identifying a market, finding problems in that marketing, developing solutions and bringing them to market. In the framework, while not diminishing the importance of the others, Tuned In focuses on the identification of market problems, requirements, use scenarios and positioning elements to illustrate the point that only by interacting with existing customers and prospects (tuning in) can one identify the problems people are willing to pay to solve. Products that do not solve a problem people are willing to pay to have solved, in Pragmatic’s view, should not be developed.
Tuned In is written in a highly readable style that is short on jargon but long on stories that hit home. A prime example of a “resonator” from the book is Zipcar, which the authors point out solves a need for a market that had not previously been met by any existing car rental company: the urban dweller who needs a car for a short time. In a recent article in Money magazine, stalwarts Ford and Hertz are cited as wanting “in” on Zipcar’s market–one which they had failed to observe and fill at any point in their long history. [It can be argued that companies like Ford and Hertz may have considered a car-sharing market but decided in self-interest NOT to fill it; the article claims that for every shared car, 20 are taken off the road, which is not good for the traditional car business]
This is a very common-sense book that is not hard to understand, but at the same time does not delve into extreme detail on topics such as market-research; academic analysis is not the point of Tuned In. Tuned In is “tuned in” to the fact that product managers need a simple, easy-to-understand process to “tune in” to their markets. And, on that, the authors deliver.
Healthcare Reform as a Product
Dec 23rd
For those of us in product management, the drama unfolding in Congress with regard to the healthcare reform package is a too-familiar refrain. Without wading into the merits of the proposal on the table right now, we’ve watched a team set an initial objective to solve a specific problem (provide healthcare for the uninsured) which has morphed over the past year as deals are cut to obtain the approval of hardheaded stakeholders. As further bargaining takes place to get votes and get the solution through Congress, we have a solution coming up for a vote that both major constituent groups are disowning for different reasons.
Take all this within the context of working in different realities (some not acknowledging the problem really exists/defining it differently), with different value systems and beliefs about whether the current forum is even the right one to address the problem, and it’s no wonder that what comes out of such a process is often clumsy and–ultimately–a poor solution. A guest blog on HBR illustrates this point with the “successful” Medicare Part D episode earlier this decade: a solution that many don’t even understand, much less support.
In product management, we advocate that there needs to be one “owner” of a problem space and solution, who makes the decisions about what form that solution takes and avoids feature creep. Those decisions need to be made with a laser focus on the problem being solved and the market itself. What we’re seeing in Congress–with all bills, really, but highlighted in prime time for us now–is the exact opposite: features added and features cut arbitrarily for the purpose of gaining stakeholder support, not because it makes the solution better. The goal of delivering something to market has taken precedence over actually solving the problem.
This is no way to build a quality product.
Startups and Product Management
Oct 11th
As I spend more time in startup-heavy Austin, I think more about the role of product managers in startup companies. In most cases, that role is implicit–there is no “product manager,” per se, but rather a CEO and/or CTO who have a vision for a product and who chair a personal quest to bring it to market. There is plenty of risk here for those who understand product management and have delivered products to market.
The fact is that as demands placed upon a startup company mount, the focus of the CEO begins to split to operational and technical issues. If someone is not dedicated to the product itself, it seems very easy — to cite but one example — to experience feature creep where people think additional functions “can’t hurt,” while they’re really not focused on the specific target market and whether or not that target market will actually use the feature being considered.
In a recent On Product Management post and the related comments, several of my peers argue for hiring experienced product management early in the life of a startup to avoid missing the target and delivering a product that isn’t a winner. I hereby add my “ditto” to those opinions.
Internal systems
Aug 30th
One of the takeaways I’m finding in Bill Jensen’s book Simplicity is a reaction to the effect that information overload has on company productivity. As there is more and more information to process to do one’s job, it becomes ever more important for a company to provide tools that not only provide access to information, but which help interpret the information in the sense of analytics. So how does this manifest for a large company aiming to produce streamlined products for the marketplace, that will address (and solve well) a specific problem?
As a product manager with a multinational corporation, I find that (at least at my company in my specific division/subsidiary) there’s a contrast between the streamlined solutions we’re being asked to produce, and the cumbersome internal systems we use to collect and analyze the information we use to design such products. The systems we’re building are “push,” but the systems we use internally are “pull.” Some of this may be due to our company’s implementation of off-the-shelf requirements management and project management tools, but the net result is that the company does not make it easier to easily understand the decisions we need to make, much less make them.
I suspect we are not nearly the only ones.
One of the products I’m developing now is a service which can run client-server or on the web, in order to maximize the base of customers to whom we can provide a solution. I’m finding that questions about–and design of–the internal management components to be used by company support representatives are getting short-changed due to the pressure to meet release targets. This is certainly not unique to this one product, and the support angle hasn’t been ignored, but at the same time the support team’s “use cases” have not been considered with nearly as much diligence and interaction design as the product itself. So in one sense, the sub-optimal experience product managers have with requirements tools is being propagated to the experience support reps will have with service management.
Something I need to reiterate within my organization.
Simplicity
Aug 23rd
I started reading a book about Simplicity titled Simplicity: The New competitive Advantage by Bill Jensen, and immediately one of the author’s assertions struck a chord. One of the book’s hypotheses (simplified) is that knowledge workers spend too much time figuring out what to do, leading primarily to diminished productivity and frustration. For large companies, much of this is laid at the feet of upper management, who may craft a concise strategy at the top but fail to disseminate that strategy appropriately within the organization.
In the case of product companies, whose effectiveness is related to how well they can develop new products and bring them to market, this is one function of product management. Product managers are responsible with becoming intimately familiar with the market’s needs in order to identify opportunities to build solutions the market will pay for, and documenting those problems and needs as requirements. (as opposed to building something we think is cool, and then struggling to find buyers)
With this role as market spokesperson, the product manager guides designers to craft a solution that will satisfy the needs so completely that buyers will be lining up to pay. In some organizations, the product manager serves as the designer as well. Either way, when that design is delivered to development, the vision, goals and solution must be clear enough that the developers can craft an accurate plan and execute without getting mired in confusion and endless analysis paralysis. Certainly the feasibility of the design must be validated before the project team is ankle-deep, but much of the programmer-as-knowledge-worker’s confusion can be alleviated by a clear vision of the solution.
Note: Modern design patterns tell us the product should also be simple and focused, but that is a topic for another post.
Jensen cites his research to assert that the 4 primary causes of confusion among knowledge workers are:
- lack of integration of change
- unclear goals and objectives
- ineffective communication
- knowledge management experience
Certainly the integration of change is a big problem during merger and acquisition activity, forcing disparate systems to be blended. Knowledge management is the problem of finding knowledge already present within the organization. But the other two–unclear goals and ineffective communication–can be addressed within a software development organization by product management.
