First, this book’s central thesis is that in the technology adoption life cycle, the most difficult progression is from the visionary innovators to the pragmatic early majority.  Contrary to the risk taking innovators, the pragmatic early majority is looking for validation from other buyers in its niche, who can validate a product will solve problems in their business.  By ensuring that the “whole product” is marketed to a specific market segment, Moore argues that a company can establish a beachhead from which to expand its presence.

The focus on a single market segment illustrates the second key takeaway: the need for proper segmentation.  Moore defines a “market” or “market segment” as a group of buyers with similar problems who reference each other during the buying process.  It is this description that helped me remember and internalize the importance of market segmentation: By posing a compelling value proposition to specific segment of the market, a company can “land” in preparation to “land and expand.”  ”Landing” requires becoming the market leader in that market.  Without market leadership, a company’s offering isn’t seen as credible.  Once market leadership exists, the members of that single market segment become referenceable clients who can speak to the company’s leadership to buyers in tangential industries, and this provides a way to get into other corollary markets.

If a company does not focus on a single market, and instead gets a buyer or two in many industries, the product doesn’t assume market leadership in any single area, which prevents it from winning any potential buyers by the power of the market leading position.  It is this rationale that helps establish why segmenting the market, and focusing on a single segment, is so important with a product and company struggling to establish itself in the marketplace.

For those learning or reviewing marketing fundamentals, this is a goldmine.  There’s a great deal of meat that Moore places around these key concepts, and so Crossing the Chasm is certainly worth reading if you haven’t already.

Blue Ocean strategy, in summary, involves examining the value proposition of a value or service to identify whether every item included is truly valued or could be eliminated, and whether any additional items adjacent to the offering could be included as a way to expand the footprint of the offering to serve additional parts of the market.

The most valuable tool I found in the book is the Strategy Canvas.  The strategy canvas is a graphical tool that represents the key value elements included in an offering, and comparing how multiple competitors position themselves to satisfy each of those key elements.  By including a “Red line” one can show where the current industry value curve sits, to provide additional perspective.  I’ve immediately found the technique useful in visualizing and describing how an already-specified product will compete and keeping focus on where to invest resources.  I look forward to applying this visualization technique to new-product development.

Sample Strategy Canvas



One of the book’s frequent criticisms is that the book doesn’t validate that commonly-cited trend-setters like Southwest Airlines or Cirque de Soleil achieved their success as a result of applying Blue-Ocean analysis and strategy, or whether they are simply easily illustrated using the book’s approach and techniques.  Scott Sehlhorst has suggested that the way to design a winning product in the Blue Ocean framework is to apply the same type of measurement to personas: measure the value each persona places on each value element, and from there design your offering around the value elements that concern the persona you are building your product for.  I recommend reviewing Scott’s post as a primer on how to apply this strategy framework proactively.

The anecdotes that illustrate the book’s key points are memorable and useful–one can easily use the stark contrasts between Cirque and its competitors, for example, as an analogy when discussing competitive strategy.  Since I was immediately able to put the book to use in my day-to-day work, before even finishing the last chapter, I can do nothing but recommend this title to other product managers.

Some of the comments from the host that I found especially helpful included:

• agilebench: “Product Manager and Product Owner are two roles, sometimes occupied by the same person.”
• agilebench – PMs – outward (customer) facing. Channel, brand, price, the whole product.  Strategic. POs – inward (project) facing. delivery, detail focused. Tactical.

The Problem: One huge problem is when one person tries to do both roles.  From personal experience, I can confirm that especially with large-scope products in multi-national corporations with products in multiple silos, it’s practically and effectively impossible.  Brainmates summarized the problem I experienced: “Market focus suffers, because it’s easier to work on tactical development activities.”  In companies I’ve been exposed to, it was not only “easier,” but there were so many fires that there was really no choice.  Because of the product’s complexity and the complexity of the organization (not to mention infighting and territorial-ism) there simply wasn’t enough time to participate in user story level design discussions, groom the backlog, coordinate sales and support, and simultaneously monitor the competition, research trends and pricing, and the other activities a business leader in the company should perform.

The Team Approach: As an alternative, agilebench suggested “can you find someone with product sympathies who can act as a proxy for you?”  This echoes an approach I’ve seen becoming more commonly cited–including last week’s Technology Association of Georgia presentation by Mike Cottmeyer–of having a Product Owner Team.  The team consists of a handful of roles that must be addressed: Product Manager handling the outward market-facing strategic functions, product owner acting as the development liason and sitting with the development team and driving home the detail around the user stories, and potentially a user experience analyst and others.  Thus as Roger Cauvin proposed, “one model is that product management is more market facing, while product owner is more inward facing.”

NOTE: Another great read about a similar topic was recently posted to On Product Mangement.

The Balancing Act: One major concern about this approach is “too many cooks in the kitchen,” or not having a single point of authority on the product.  I think the split approach can work, if and only if the members are diligent about remaining aligned on a daily basis.  Another alternative is a balancing act: The PM/PO must be accessible to the team at all times, yet must get in front of customers and the other teams within the company to ensure a successful rollout.  This balancing act can work if the team is talented and can work (at times!) without direct input from the product owner.  A few calls and meetings spread through the week is one thing, but if the product owner is rarely visible except for the daily scrum, even a seasoned development team may be hard pressed to succeed.  Conversely, if the product manager never leaves the scrum room to speak with customers, the team is at serious risk of building the wrong product “successfully”!

Two Pounds In a One Pound Bag: Given more than a full-time job’s worth of responsibilities outside the scrum room, and nearly another within, it should be inherently obvious that a product manager should not be placed in the impossible scenario of performing product manager and product owner responsibilities on two products at once!  I can also confirm this from personal experience.

Other Topics: Other topics were discussed, including

• how to gain the respect of the development team
• how to break up deliverables when more than one product manager is on a single product
• when are agile methods not suitable for product management
• How do product managers ensure the vision when agile delivery teams are focused on small pieces of work?
• If it all needs to be done why does it need to be prioritized?
• How do you roll up individual projects into an org-wide roadmap aligned with company strategy?

Plenty of great discussion on all points is archived and available in PDF (start at the bottom!).  Enjoy your read!

First, a former coworker expressed that he spends time with his developers when possible to get their input when writing requirements.  While technical team input is certainly warranted, some of the primary benefits of agile are harvested only when the product owner sits in the “war room” with the development team during construction of the product.  My former coworker expressed that he travels, so this arrangement is followed when possible.

In an agile organization, it may be that to account for a traveling, semi-available product manager–one who may be doing exactly what his product needs, spending time in the market–the best solution is to appoint a full-time product owner to the product.  The product owner can spend time with the development team to make product decisions on a story-by-story basis, while the product manager is in the market, attending trade shows and visiting customers.  If the two are able to stay in concert, the additional investment can pay off with a product that meets two very important goals:

1. Being attuned to market needs,
2. Constructed to meet the vision of the product’s evangelist.

For additional reading on this topic, start with Rich Mironov’s insightful slide deck entitled “Agile Product Manager, Agile Product Owner.”

Changing gears a bit, Roger Cauvin this week retweeted a link to his classic post titled “Agile is Not Just a Development Methodology.”  In it, Roger posits that the benefits a product manager can obtain by working in an iterative, inspect-and-adapt process are perhaps more significant than the benefits a team obtains when developers work in this fashion.  A product manager can use the input from customers and the “business at large” when planning each sprint, rather than constructing a complete set of requirements up front and hoping they’re still correct by the time construction has completed.

This is certainly motivation to support an agile development team, and can apply to monthly releases or initial releases.  The flip side is that there are (at least) three types of initial product releases:

1. Initial releases where a minimum marketable feature set must be constructed before release can occur.
2. Initial releases where the marketability is more nebulous, and where realtime input is necessary to identify the point at which the product can be released to market.
3. Ongoing releases where customer input is consumed regularly.

When entering a market in which established players exist and where speedy release to market with at worst a comparable product is the order of the day, the product manager may already have identified a minimum feature set that–reminiscent of waterfall processes–must be constructed in order for an offering to be at all viable.  Going forward from that initial release, additional features to be added to the product can be vetted against real initial-release customer feedback as well as market needs.  During initial construction, the product manager validates the original assumptions and concentrates on the user experience, to ensure the best possible initial release.

When entering other markets, customers can be brought in to evaluate each iteration and can help to determine when the problem is solved “well enough” to bring it to market.  This mindset may be hard to achieve in a SaaS environment, where a monthly release schedule dictates that a release will go to market on a schedule.  Teams may address this challenge in a couple of ways:

• Conducting work on solving the problem in each iteration and release, but not surfacing the functionality until the team decides it’s ready.
• Skipping a monthly release but still iterating, and releasing only when the feature is “ready for prime time.”

The third category, where a regular release schedule is maintained and customers are regularly consulted, is the most closely aligned with Roger’s position and is where agile product management can truly deliver the highest ROI.

What I do want to touch on is the value ProductCamp provides to those attending and participating (preferably everyone there is both!).  We just held ProductCamp Atlanta 4 yesterday, and one tweet from presenter Jason Moss really summed everything up:

Just leaving Product Camp. This was one of the most amazing and educational days in my career. THANK YOU ALL! #pcampatl

This is why people volunteer to conduct ProductCamps, present content, and spend a gorgeous Saturday afternoon inside a conference center sharing and learning about product management and marketing topics.  Product Managers usually only work with a small team of people that are like them — and work with a business-at-large that thinks quite differently (from Paul Young’s “X-facotr” presentation–see slide 12).  A day devoted to topics related to our line of work, with our peers, is hard to come by.

The fact that ProductCamp occurs on weekends demands a degree of self-selection — product managers who aren’t slightly maniacal about their careers and doing their job to the absolute maximum of their capability aren’t going to spend a Saturday in a conference center.  As a result, the caliber of people you find at a ProductCamp exceeds that of many other conferences — these aren’t people who are guilted into showing up because their company enrolled them.  These are people who made a conscious decision to spend the day advancing their skills and knowledge, and meeting people like them.

In the opening session, Jason Brett asked how many in the audience were at their first ProductCamp — and on this particular day, about 50% of the audience stood up.  So i was interested to see what these people thought of ProductCamp.  So here are a few other comments that validate the time and effort:

From Eric Martincek: ”Thanks to everyone who made ProductCamp ATL #pcampatl a great success. This was my first & plan on attending the next one.”

From Desiree Peeples:  ”Thanks so much for allowing me to be a part of such an amazing event… looking forward to next year!!!”

Also from Desiree: “#pcampatl ROCKED this year!!. If you weren’t there–you missed out!”

From Kellie Jones: “Great day. Awesome people. Good sessions. Sublime donuts and RiRa. #pcampatl”

How does ProductCamp get this kind of reaction?  Aside from the self-selection mentioned earlier, people attending ProductCamp vote on session topics — so the democratic process encourages topics that the vast majority of people want to see.  This time there were 32 proposals for only 16 slots — no room for sessions people were only marginally interested in.

So to sum up, if you haven’t paid much attention to ProductCamp Atlanta in the past, but you want to see what the fuss is about, check out pcampatl.com!

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.

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.”

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.

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.

I’m currently running a large development project which is transitioning at the 2/3 mark from waterfall to agile.

Now that I have that out of the way, a little background.  The project was defined in terms of discrete requirements, originally tied together with a few key workflows and wireframes, and involves an n-tier architecture with a number of moving parts.  Though much of the underlying architecture was completed, we weren’t clear enough about the workflows and stories and the project was not producing tangible results fast enough.  So, while we recognize we should have started with agile, the company hadn’t adopted the agile methodology at inception.  To achieve our goal of better predictability and periodic peer review of the software, after it became possible in the corporate environment, we moved to agile.

Note that in the first half of the project, we erred on the side of providing requirements that stopped at the “what,” rather than providing the team enough about the “how.”  The move to agile has exposed that we weren’t providing enough context around each requirement (story) to enable the development team to build the product.  In this case, the complexity of the project and an unfortunate number of unknowns has made it useful for product management to collaborate with user experience well before presenting user stories to the development team, as advocated by others, rather than attempting to involve UX on an “as-needed” basis for each story.  In prior attempts to provide only the agile user story in “As a ___, I need ___ so ____” format, it quickly became apparent that the story wasn’t nearly enough.  We had to deliver the agile user story with the workflow steps (including interaction design) — only that seemed to eliminate enough uncertainty to proceed.

From a higher level, there’s another lesson here that operating under both paradigms has exposed.  It was quickly clear that for a complex system, providing the complete user stories and supporting material (including workflow steps, interaction design and wireframes) enables undesrstanding and fast action.   Though it was in some ways coincidental that we had wireframes before our sprints kicked off, it already appears to have sped things up significantly.

Hopefully the ramp-up will expand as we continue down this path, and we’ll reach the finish line quicker than we might have otherwise.