The Product Owner Vision
Agile Product Strategy, Marketing, ProductCamp and more.
RT @celia: (via @StephenFleming) Steve Blank: "The golden age of Silicon valley is over..." m.theatlantic.com/business/archi… @sgblank
Applying Product Management Principles to Small Business Development
147 days
In the course of nurturing our Atlanta crepe and catering startup, I find myself applying product management and principles and strategies to the development of the business. I thought I’d share a few examples:
Segmentation: My wife’s perception of the business is that it is a “farmers’ market vendor,” but I prefer to think of it as a mobile crepe vendor. We both recognize that her focus on farmer’s markets is a manifestation of her operations mindset. In reality, farmer’s markets are a way to gain exposure to the marketplace and get one’s name out; the real profit is found in private event catering that affords a higher revenue stream. We have implemented additional tactics to reach the previously unidentified segments of office personnel and wealthy party hosts.
Tactics and Strategy: Recognizing that party hosts and offices are a significant segments of the market that we need to account for, we implemented tactics to make sure we reach them. Our website and SEO activities are being deployed to reach those searching for crepe parties, crepe catering, and crepes in Atlanta in general. We’re slowly seeing results here, as we’ve had three private event inquiries in the last 6 weeks after zero in all previous weeks.
Partnerships: We are taking concentrated effort to reach out to friends with small businesses, with which we can imagine mutually beneficial relationship. In this way, we’ll be able to extend our offering to provide a more complete solution to clients’ needs that we cannot solve on our own. Over the next several months, we’re hoping to announce a few events in tandem with other related businesses.
Since the business is only six months old, there is plenty of ground left to cover! However, I’m happy to recognize the value that product management provides in terms of marketing and positioning a small business.
The business needs product management to be agile, too.
162 days
Let’s not kid ourselves, when it comes to building and marketing business solutions, we’re not building software as part of a science project–we’re in this for the ROI. The business doesn’t care whether you’re agile or waterfall or something we haven’t thought of yet, as long as that return is delivered as promised.
That ROI can only be delivered by fulfilling the primary purpose of product management: creating a compelling solution to a pervasive market problem that buyers are willing to pay to solve. Lean Startup refers to “product-market fit,” which ensures that not only do you have a market problem buyers will pay to solve, but that the solution you are delivering is the best one possible. That fit isn’t present until your users can’t live without the product. Such a fit can only be achieved by imagining a solution in tandem with a designer and a technologist, and then iterating based upon real customer input–or, as it were, being Agile. Agility is in product management DNA, and by far is NOT simply a more adaptive project management framework.
B2B products have traditionally focused less on design than B2C, but I firmly believe the consumer’s expectations have been raised so high by revolutionary User Experience (UX) in products like the iPhone that startups in B2B will overtake established companies if they don’t invest more in UX. Enterprise software can’t continue to underwhelm–so product managers can’t hand design over to engineering and avoid being involved in design.
Product managers are traditionally owners of the problem space, but they need to play an active role in the solution space also to achieve optimal product-market fit. By ensuring thoughtful, user-centered design, the solution can be as good as the definition of the problem. Agility is a product development approach that helps get to product-market fit faster, which is what Greg Cohen and others call Lean Product Management.
It is not enough for product managers to throw a PRD or MRD over the wall to engineering after passing the relevant gate, and for engineering to begin developing the product in two-week iterations. That’s not agile! The business needs product management to be agile, too. If your engineering team is iterating but you haven’t validated that the solution is the right one, why are you still building something you haven’t confirmed the market will purchase?
Product Management should be bringing new market insights on a regular basis both before and during construction, and Product Management leaders should track how frequently backlogs change. Markets change; customer visits reveal new insights. If a backlog is too static, the product manager isn’t getting enough input! Certainly the top of the backlog, the most important items, should be relatively solid, but anything below them is fair game for perpetual re-evaluation. And it’s the product manager’s responsibility to continually re-evaluate–or in scrum parlance, groom the backlog.
Product managers should think Lean Startup: Work towards MVP using prototypes [Build], get user feedback [Measure], and adapt [Learn] to achieve optimal product-market fit. Once released, each subsequent major enhancement should go through the same cycle–prototype, get real user feedback, finalize. Don’t just play product owner, sit in the scrum room and shepherd your static backlog through the development process. Be agile!
Lean Startup: Build - Measure - Learn
“No Salespeople! I’ll call when I’m ready to buy.”
0“No Salespeople! I’ll call when I’m ready to buy.”
That’s the quote I heard in a B2B Marketing seminar at this weekend’s B2BCamp. The quote was attributed to CIOs of major corporations, who are finding less and less time to be entertaining phone calls and visits from salespeople–even those who are trying to help them with real problems they’re facing daily.
Executives and decision makers have less than zero time. When they have problems, they turn to Google. It’s up to you to make sure you’re there when they go searching. In the early stages, your marketing automation needs to be feeding that buyer subject matter expertise and thought leadership to help them understand the symptoms they’re seeing daily and recognize the core problem. In the later stages, you need to be there with the appropriate product information and an easy way to transition to a sales representative. But be certain, it’s all about the buyer.
This is profound. And it’s the future.
Judy Mod and others call this being “buyer-centric.” I call it knowing your target market and all the personas within the buyer team. Sadly, my presentation with Kevin O’Malley–an earlier version of which, recorded without Kevin, is available here–was not offered at B2BCamp, but it would fit nicely into this narrative. The personas relevant in this discussion aren’t necessarily the primary users of the product, but rather are the person interested in the purchase, influencers who need some sort of dashboard type data as output, and so on. Modern B2B selling requires that the information needed by each be available and offered up on a platter at the right time.
If you don’t understand those buyer types, go out and listen to the market. If you do, make sure you communicate them effectively inside your organization–and consider using personas to achieve that objective.
Inaugural B2BCamp Atlanta
069 days
Yesterday, I had the pleasure of attending the inaugural B2BCamp Atlanta, an unconference aimed at the growing B2B Marketing concentration in Atlanta. Lots of great thought leaders were present at the event hosted at Matrix Resources, and 12 educational sessions were offered.
Unfortunately the session that Kevin O’Malley and I offered was not selected, but that gave me the opportunity to sit in great sessions about being Buyer-Centric, the use of video, and a marketing automation panel. All in all, great learning opportunities all around!
Opening Session - photo by Adam Needles
As organizer of ProductCamp Atlanta, the format was refreshingly familiar, but the content was a nice foray into content I’m not exposed to quite as often. I want to commend the team on their execution to deliver a first class marketing event in Atlanta, and I certainly look forward to the next B2BCamp!
Interview: Rich Mironov
2159 days
Last week, I had the pleasure of interviewing Rich Mironov. Rich is an accomplished product executive and startup veteran who’s spent significant time evangelizing agile product management. Rich also founded the very first ProductCamp in Silicon Valley, and wrote The Art of Product Management based on content from his Product Bytes blog.
Rich and I spent about half an hour discussing three primary topics: ProductCamp, Agile Product Management, and the Product Management career path. Some of the specific discussions included:
- How ProductCamps can increase awareness among senior and executive level product management.
- How product managers can help engineering organizations to understand everything that product managers do outside of engineering to help ensure the success of a product.
- What are the options for a product manager to advance in the field.
Rich provides great insights in a relaxed, disarming style. Rich can be reached at his blog (http://www.mironov.com) or by email at rich@mironov.com.
Enjoy!
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.
Shared audio file for those who need to access it outside the blog, via Box.net
Buyer and User Personas – the Presentation
0161 days
The Startup Slingshot was gracious enough to offer me an opportunity to deliver my Buyer and User Personas session that I delivered at ProductCamp Atlanta with co-author Kevin O’Malley, and alone at ProductCamp Nashville, in the form of a video blog post.
If you have 25 minutes to burn, here’s the presentation:
Product Management and Solution Design
3185 days
A valuable reminder was posted by Martin at Mind the Product today about focusing product management attention on the problem space, rather than the solution space:
At a ProductTank last year one question from the audience made me want to jump up on stage and answer it myself – “where’s the innovation and creativity go if product managers are defining all the products?”. Stop, I wanted to shout, you’re doing it wrong….Product managers should not focus on designing solutions – they should focus on defining and prioritising problems.
Product managers generate value for their companies by finding market problems that potential customers will pay to solve, and then leading the process of finding a feasible and compelling solution.
This does not mean the product manager designs the solution, in fact, many are not trained to do so. That distinction is drawn clearly in a post from 2005 by one of my favorite product management writers, Roger Cauvin:
A product manager determines the requirements for a product, but not its design. Thus a product manager specifies what a product should do (functional requirements). She also places constraints on the product’s behavior (nonfunctional requirements), such as how easy to use it should be. But placing constraints on a product’s behavior does not mean specifying the product’s design.
A product manager is uniquely qualified to learn what the market demands and translate this knowledge into product requirements. But only an ergonomist or user interface expert is qualified to design a product that satisfies these requirements. How many product managers are trained in user interface design?
It is far different to find–and then define–a market problem than it is to figure out the best way to solve it. Many are guilty of confusing the two.
Where it concerns product design, I subscribe to the Marty Cagan “Product Discovery” model for designing winning products. In Marty’s model, the product manager brings an understanding of market problems to the table, and collaborates with the other two key members of the product discovery team–the user experience designer and the lead developer–to discover the right solution. That solution is discovered by brainstorming, generating a high fidelity prototype, getting real user feedback and then brainstorming again to iterate on the prototype, repeatedly until an optimal solution is “discovered.”
The key point relevant to Martin’s article is that the product manager isn’t designing the solution–the product manager leads a team of three to design the best solution. Marty explains in an insightful post on designing winning products in a large organization:
The key for every product discovery effort is to identify the three key people – the product manager, the user experience lead, and the product development lead. These are the three minds that must collaborate closely to solve problems in new and useful ways.
I’ve seen teams repeatedly in which user experience and product management collaborate on their own to create a design, and then find out too late that the design either (1) just won’t work, or (2) will be too costly to deliver to market in an acceptable time frame. The design isn’t the purview of the product manager individually, nor is it that of the lead developer. Product design is a collaborative effort.
Here’s Marty discussing, as he calls it, the Product Discovery Team:
Updated personas presentation
0187 days
I’ve updated the presentation I delivered on User and Buyer Personas in Design and Strategy on Slideshare. I delivered this at ProductCamp Nashville on November 12, 2011.
Personas in Design and Strategy
View more presentations from John Peltier
Should the product manager be product owner for new product development in Scrum?
2243 days
In an earlier post, I wrote that the model of having a strategic product manager partner with a tactical scrum-team-immersed product owner delivers business value best under limited conditions. As this will be one of the most controversial topics during my talk tomorrow on #ProdMgmtTalk, I want to reiterate my rationale here in a more verbose form.
The two conditions I listed are:
1) The product is marketed to a segment of customers, not just one.
2) The product is already released to market, and is thus beyond v1.0.
The "Product Owner" without Product Management responsibility is really a Backlog Manager.
Delivering business value in this context means developing a product that meets the needs of the market, and fulfills the product vision that capitalizes on market opportunity. In the stage-gate days, product managers would “capture” that vision in MRDs and PRDs and toss them over the wall, and then be frustrated that the product which came out the other end did not deliver. By providing periodic visibility of work product, Agile processes are often implemented to address this long-observed waterfall limitation.
I suggested that in other conditions–specifically mass market products during intitial development–companies may wish to consider having the product manager serve as product owner, in order that the person with the best knowledge of the market and problem space is guiding the product’s development. This blog is an attempt to clarify some of the arguments supporting this position.
My suggestion generates much contention among ISV product management purists. In agile development in general–and scrum, specifically–heavy demands are placed on the product owner. Chief among these demands is the regular management of the backlog by breaking down high priority user stories, and the need for consistent availability by the development team. Product owner availability ensures the development team has the resource necessary to explain the rationale for features, and to work with team to validate the best way to implement each user story.
Product managers are members of the business, not of the technology team. They are responsible for identifying market problems that people will pay to solve, which can most effectively be done by spending time with customer representatives and studying the market rather than by spending time in the scrum room. Product managers must interface with the rest of the business in order to coordinate the surrounding roles: creating training guides, helping marketing with positioning and messaging, sales support, etc. Product managers are often responsible for more than one product, leading their focus to be strategic rather than tactical.
Clearly, these two roles cannot be the same person! Or can they? I believe there’s a case for these two roles being occupied by the same person during the initial release of a product.
When companies implement scrum, common guidance states that product management needs to staff up by adding a product owner to the ranks to support the product manager. I believe in some company cultures, this remains the best option. I believe, however, that an alternative model should be considered: While release 1 of a brand new product is under construction, the product manager works only on that product and serves as product owner on the scrum team personally.
This proposal implies a redistribution of responsibility among the product management team — someone else must manage the product manager’s other products to allow the product manager singular focus on the new development. Many teams won’t be able or willing to make this sacrifice, for one or more of many reasons including (1) there aren’t market experts to replace the product manager on the other products, or (2) the cost of bringing in a product owner on the new product is lower. However, there is a primary disadvantage to keeping the product manager on multiple products including the release-1 effort: Lack of Focus.
A Product Owner is often brought in to partner with product management as part of the “product owner team” or “product discovery team“. This arrangement usually involves the Product Owner meeting regularly to ensure day-to-day execution of the product manager’s vision, while the product manager meets with customers, develops pricing, champions the product, and manages the other products in the product manager’s portfolio. Conversely, the Product Owner may not have the luxury of all the customer visits, market research and competitive research the Product Manager used to develop the business plan and the product vision.
This lack of focus is the problem.
The Product Owner is encouraged to be in the scrum room during a majority of his time, to help with all the day-to-day decisions that go into building the right product. In this arrangement, this means that the person with the deepest direct knowledge of the market and the problems the product is intended to solve…isn’t. When called upon to explain rationale and help with interaction design, or any of the other elements about which the product owner is asked to participate, the product owner must rely upon limited customer interaction and second-hand understanding obtained through others. This leads to weaker positions in discussions with developers, and may have unintended consequences that manifest in the design of the app. These consequences may not be related to something the product owner says–in fact, it may be because of something the product owner doesn’t say.
To implement this, it may require a bit more sequential thinking than scrum purists would support:
- The product manager builds out market justification and designs the solution (with the lead designer) before starting construction.
- The product manager allocates a majority of time during construction to development team support.
- During buildout, the product manager strategically allocates mid-sprint time to customer visits and product reviews. This time after working through the current sprint user stories and before the race to capture points at the end, is often a quiet time for the product owner. Note in a two week sprint, this may be roughly 4-5 days of a 10 day sprint.
This last point illustrates why this requires allocation of the product manager to the new product exclusively — there isn’t leftover time in this model to work on other products. When exclusivity is not an option, the product manager works with the product owner to ensure the solution addresses the market problems. As I’ve mentioned, this separation is risky.
One way to counter the risk is to bring the product manager in when anything important comes up, however, it’s very difficult to determine which instance of the “butterfly effect” may require the presence of the product manager. Often the product manager is unavailable, and delaying an answer to arrange a conversation may interfere with the team’s velocity.
Another option is to have the product owner conduct the competitive research and customer interviews to ensure they are market experts as well. But then, isn’t that blurring the lines and having the product owner serve as product manager? And if they’re showing prototypes of the product to customers throughout the construction process, are they as available as the development team needs them to be? Perhaps teaming with a product marketing manager can offload some of the outbound marketing and sales responsibilities, but there will still need to be someone with product and market knowledge guiding the sales of the product and its positioning in the market. And the product owner in this case will be doing a lot of the inbound marketing that is the core of product management.
Are there other approaches? Can these challenges be resolved by having another member of the design team–the user experience specialist–available to the team as well?
Please share your thoughts in the comments.
ProductCamp is over…on to #ProdMgmtTalk!
0246 days
Another fantastic ProductCamp is in the books–that’s #5 for Atlanta–and the planning team is busy working on what’s coming up next. The two at top-of-mind are listed here; however, please follow us on Twitter to make sure you don’t miss anything!
- - Please complete the ProductCamp 5 Wrap-Up Survey
- - Please post your ProductCamp 5 Content on SlideShare
We’re giving ourselves about 10 days before we start thinking about the next event, possibly a happy hour in the Fall. Some of us are already making preliminary plans to visit our neighbors in Nashville for their first ProductCamp ever on November 12. Perhaps you might want to join us?
With a nod toward the session I led at ProductCamp this past Saturday, I will be the guest of honor on the next #ProdMgmtTalkTwitter chat which occurs at 7pm Eastern on Mondays. This talk is hosted by Cindy Solomon and will be co-hosted by Roger Cauvin, who I had the pleasure of meeting during my time in Austin. I find Roger’s blog to be one of the best-written on the topic of product management, with particular emphasis on agile approaches to the subject, and I look forward to his participation in the talk. Cindy and I have spoken about focusing the topic of our talk around backlog management during development of the initial release of a product, as that is an area I’ve uncovered (and..caused!) some controversy. Hope you can join us next Monday.
Recent Comments