John Peltier
Agile Product Management, Marketing, and More
Blog Relocated
Sep 15th
This blog is being rebuilt under a subdomain to allow for future additional development.
New posts can be found at http://johnpeltier.com/blog
Where “Product Owner” as “Backlog Manager” fits best
Jul 22nd
In a recent post, Saeed Khan wrote that the Scrum role of “Product Owner” should be redefined to describe a more accurate set of responsibilities: “Backlog Manager.”
Saeed’s argument is that the Product Owner role is really a project-specific role implemented within the Agile movement as a solution to inaccessible product management. Saeed observes that more and more product management responsibility is bleeding into the Product Owner role, which is intended to be the funnel of business input to the development team. This conflicts with the primary responsibility of the role, which is to provide a set of fully groomed user stories representing the next most important features that should be built, and to be available throughout the sprint to answer questions.
After considering this since Saeed’s post, and based on my own experiences on four scrum projects, I’ve come here to propose that there is a “best case” condition under which this arrangement makes sense, and several others under which it doesn’t quite work.
The Case where a Backlog Manager makes sense
The first thing to remember is that Scrum has infiltrated software development from the custom software world. When building custom software, there is a single customer whose wants and needs are primary — and time has shown that having a representative of the customer in the war room at all times can help the development team deliver something meeting the customer’s needs in an efficient manner. In this context, because the Product Owner is often an employee of the client who has broad and wide domain knowledge, it makes sense that a single person bears all the responsibility of the product–and it makes sense that a single person can deliver it! This set of conditions does not demand that we separate the tactical “product owner” responsibilities from the business “product management” responsibilities because they are so intricately tied together–and the product is being built for one customer!
When we look at independent software vendors, however, we encounter the difficulties with balancing the strategic and tactical that many Product Managers express. A product manager must synthesize the needs of a market segment to deliver a compelling offering, and successfully prepare it to be marketed to that segment. If the Product Manager (title) occupies the role of Product Owner, spending much of his/her time on tactical items for upcoming sprints, the pattern seems to be that access to the market is less common.
It is at this point that the notion of “Time” becomes important. I believe the tactial responsibilities of backlog management can be offloaded by a Product Manager to someone filling the role of Product Owner (a Technical Product Manager, a Business Analyst, etc) under one condition: After a product’s initial release to the market.
In my ideal process, before starting construction of a new product, the Product Manager will spend significant time in the market understanding the problem space, developing business case and initial requirements, to the degree that he/she is prepared to spend a number of months focusing on development. It is only with this focus that a clear vision of the product can be brought to the team and shepherded to completion.
Backlog management will take a great deal of time, but the product manager’s command of the entire product is essential to having it built correctly. With a competent team, the Product Manager serving as Product Owner can still find time to make periodic visits to customers to get feedback on early builds and gain the input needed to “inspect and adapt.” But if this feedback only reaches the team second hand, the risk to the cohesiveness of the product is too high.
After version 1.0 of a new product, when the product is in customers’ hands and is being considered by prospects, the vision, business case and purpose of the product is already established. Now that the product is built, the product manager is looking for additional market segments and business opportunities, finding the problems which adding solutions into the product would open up new markets. Additional important and complex features may be added, but the basic nature of the product is already set. Given this stability, the profitability of this product can be managed by one individual, while the tactical implementation of new features can be efficiently offloaded to another. This is the case where separating responsibility between a Product Manager and a Product Owner makes sense.
These three statements summarize my position:
- For custom software vendors, there really is a single “product owner” that fits with Scrum orthodoxy. This “Product Owner” is a representative of the customer.
- For ISVs developing version 1 of an off the shelf product, a single person should own the business and technical sides of the product. That single person learns the market and helps build the right solution.
- For ISVs developing later releases of an off the shelf product, the backlog management responsibilities can be split from P&L / business responsibilities. The boundaries are set, and a “backlog manager” or “technical product manager” can work with the Product Manager to understand the goals of the next release and execute, while the product manager coordinates sales, channels, support, and other arms of the company.
Special Note: During the development of a Version 1.0 release, because it makes sense to have the single person with best understanding of the business case overseeing the development effort, in most cases it does NOT make sense to have one person overseeing the buildout of more than one product! The workload to understand business needs, positioning, usability needs, requirements and user stories, and implementation details is too great to split that person’s time into multiple threads. I can confirm this from personal experience!
Lessons from ‘Crossing the Chasm’
Jul 9th
Crossing the Chasm by Geoffrey Moore is a classic reference book for marketers of technology products. As a review, there are a couple of key takeaways in the book that serve as reasons everyone marketing technology products should read it.
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.
Thoughts on the Social Media scene in Atlanta
Jul 4th
Let me begin by saying: I’m seeking contrary opinions.
I’m synthesizing my perceptions of the social media scene in Atlanta, Georgia as it compares to the scene in the city I relocated from, Austin, Texas. Both cities consider themselves social media “capitals,” but they are very different from each other. Having lived in both and participated in the Austin scene, I want to paint an early picture of how I see Atlanta’s scene and see if it resonates with others.
Atlanta’s scene seems less populated with casual social media users, and is more occupied by the professional media/marketing/PR crowd, than I experienced in Austin. This is not bad in and of itself, but it does represent a great opportunity to build stronger connections within the community in the Atlanta area.
First of all, the cities are vastly different. Austin is a city of semiconductors, internet startups and recent graduates of the University of Texas. Oh, and Dell. Metro Atlanta is 4 times larger than the Austin area, and it’s dominated by Fortune 500 companies which drown out its surprisingly large internet startup scene. Several universities in and around the area contribute to its technology talent pool. But it is primarily a large-company city.
These cultural differences contribute to the social media climate. In Austin, social media events are dominated by startups, casual social media users, people seeking work at startups, college graduates, and a few representatives of larger organizations. In Atlanta, in my admittedly limited experience thus far, the scene is more strongly dominated by representatives of the Fortune 500 companies and marketing firms serving them, as well as students seeking to work in the marketing/PR/social media space within large companies. Some startup folks participate, but others gravitate toward startup-specific events (such as SUDS).
Due to the composition of the people involved in social media, social media events in both cities have a different feel. In Atlanta, they revolve around seminars on how to apply social media techniques to messaging efforts in the enterprise. In Austin, at events like BASHH and Austin Tech Happy Hour, it’s about small startups finding relationships to support and expand their business. Thus Austin’s events tend to be a bit more open and welcoming, where Atlanta’s feel a little more like a convention. The Social Media Day had a surprising number of people from local radio and TV stations and locally-headquartered national news organizations. Heavy emphasis on the “media.”
To me, social media is more about the “social” than the “media.” The recent Social Media Day event in Atlanta, sponsored by a local media outlet, was the first time I had people look at me strangely when they realized my “day job” is not media-related. They wondered why I was there! I wondered why others weren’t, though I realized: there aren’t many non-”insider” social media events in Atlanta to help build that feeling of community.
This was one of the major reasons for putting on the inaugural Atlanta BASHH, and why I already look forward to the next. BASHH is an event strongly oriented towards crossing boundaries, mixing groups, and involving casual social media users. The breadth of people that attended was phenomenal. Helping people understand viscerally the benefits they can obtain by participating seems much more rewarding on the interpersonal level than showing Powerpoint slides about how to use Twitter better. I had no strange looks when I volunteered I don’t work in media at BASHH.
Is this contrast I’m painting due to the nature of the companies and opportunities present in the two markets I’m comparing? Am I unfairly characterizing the scene in Atlanta (or the scene in Austin)? Tell me in the comments!
The Strategy Canvas
May 1st
I recently read a copy of the book Blue Ocean Strategy: How to Create Uncontested Market Space and Make Competition Irrelevant. As many have observed previously, this is a great source of inspiration and food for thought, and well worth the investment of time from product managers.
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.
ProdMgmtTalk: Product Manager vs. Product Owner
Mar 22nd
Today’s Global Product Management Talk, a weekly realtime Twitter conversation among product management professionals, covered the topic “To Agile or Waterfall…Does it Matter?” featured John Mansour, CEO of Agile Bench. As an agile product manager, I looked forward to this conversation despite that its timing at 6pm Eastern prevented me from participating realtime. The first posted question was “Product Manager, Agile Product Owner, What’s the Difference?” Since this is near and dear to my heart, I’ve composed my response here.
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!