Agile Product Management, Marketing, and More
Product Management
Book Review: Agile Excellence for Product Managers
Jan 22nd
Agile Excellence for Product Managers by Greg Cohen is, in my view, the best introductory “how to and why” guide to Agile and Scrum for product managers available. There are other great resources touching on specific elements of methodology–such as Mike Cohn’s User Stories Applied–but Agile Excellence puts those techniques into context and explains the benefits of iterative development, the impact of iterative development on how the product manager conducts his activities and why it helps the product manager conduct those activities better than under a traditional development methodology.
Agile Excellence introduces the product manager to agile in a deliberate sequence. Starting with the benefits of iterative development, Cohen covers the specifics of Scrum and then gets into the details of release planning. In my experience, some teams try to “sprint through the backlog” without considering the contents of a specific release — the release planning chapter illustrates a technique for thinking this through to provide marketable value to customers over a series of iterations. To bring the product manager up to speed on writing requirements in the form of stories, Cohen goes into detail about user story management including the types of stories that exist and techniques for splitting the large ones. Examples are provided to illustrate when a story is too big to estimate granularly. This section is not nearly as comprehensive as Mike Cohn’s book, but it’s good enough to get started without lacking the basics.
Cohen shows how to move from ideation to a prioritized backlog, and how the team is able to deliver value to the business early and often by doing so. Agile Excellence walks through creation of a product strategy, followed by a release plan, creation of the product backlog, and finally estimation of the stories using the Planning Poker technique. With a team working on an estimated product backlog, Cohen considers how a product manager interacts with the team and with the business at large (including customers), and discusses signs of trouble and how to react. Finally, for context, Cohen spends a bit of time on XP and Lean development including Kanban.
One of the important points Cohen makes is that Agile and Scrum are essentially a project management approach rather than a development methodology. Development teams need to adopt new techniques to meet the tight deadlines agile demands, but these techniques are not elements of agile. Agile simply assumes the team is “self-organizing” and will make the changes necessary to succeed. The fact that those changes often include pair programming and test-driven-development is left to the development team to discover, however it is useful for a product manager to be aware of them in the event they are evangelizing agile to an organization.
I highly recommend this title for product managers new to agile, and to those needing a refresher. This book puts agile techniques in context, gives enough “in the weeds” level detail, and explains why these techniques are useful and why they make a difference. It’s the book I wish I’d read before beginning to work with a scrum team.
So many products, so few gems
Jan 16th
The pace of technology innovation is unabated, even growing, and yet it’s commonplace to see new products released that don’t resonate. Either the products are good but are poorly marketed to their target buyers, or they are not solving a real market problem. I believe this signifies a need for better product management in technology companies.
Jim Holland speaks to this in his recent On Product Management post, A Product Leader’s Perspective of CES [the Consumer Electronics Show]. In it, Jim summarizes the situation:
It’s a shame really. You know the products. Ones that were designed and developed because they COULD, not because they SHOULD.
Jim cites a previous post I’d written in which I proposed four artifacts that a product manager can use to define a proposed product:
- The problem being solved
- Buyer and User Personas
- Value Proposition
- Solution Workflows
In an agile or scrum environment, it may only be the core workflows – much of the finer detail and other workflows may be emergent. But the basic workflows must be in mind, or there isn’t enough definition around what is to be constructed.
I propose that if the product manager or product owner can confidently communicate these four items, he is on the way to delivering something of value to the market. The challenge is to clearly identify these items before building the product — and if they can’t be identified, this is a golden opportunity to avoid investment in a product that will become one of the many developed just because someone could.
The Product Owner Vision
Jan 2nd
A recent article by David Alfaro summarizes well the core competency of a product owner in scrum / agile development organizations — the ability to consume all the inputs, mix them together and design a cohesive, marketable product that will meet the needs expressed in the inputs. Not surprisingly, this sounds a lot like product management. Here’s how Alfaro expresses this core skill:
After you have listened to all the aforementioned stakeholders the following two hardest steps are ahead: 1) Synthesize all that input into something really remarkable, feasible to implement and affordable for customers. 2) Communicate that synthesis to stakeholders and team in order to go for it.
There are (at least) two major views of this. Design-driven organizations would likely agree with Alfaro, perhaps with the added input and agreement of a design team (artists and interaction designers) on the front side to craft the behavior of the desired product. Others that take a more “agile” approach may guide the product owner to focus on the problems, presenting them to the team in the form of stories and allowing the team to design the solution within a pre-determined set of parameters.
Either way, the product owner’s job is to define with more or less granularity the “what,” and to guide the team to analyze and implement the “how.”
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.