John Peltier
Agile Product Management, Marketing, and More
Thoughts on Agile Product Management
Feb 25th
A couple of thoughts/lessons about Agile product management were brought to my attention this week.
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:
- Being attuned to market needs,
- 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:
- Initial releases where a minimum marketable feature set must be constructed before release can occur.
- 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.
- 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.
The Value of ProductCamp
Feb 20th
ProductCamps have been around several years now, and plenty of words have been written about the experience from all sorts of perspectives. ProductCamp Austin founder Paul Young wrote a frequently-referenced description of ProductCamp, so I won’t re-invent the wheel here.
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!
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.