Product Management is often seen as a simple matter of inputs and outputs — we take information from the field, from the market, or from the users, and we create new products and features that meet their needs. If only it were that simple! Customers rarely know what they really want, although they can be very vocal about what they “need”; sales teams are often focused on the last deal they lost or the next deal they’re trying to close, and market intelligence can often be muddied by statements and claims by competitors and thought leaders which can be hard to distinguish marketing spin from product fact.
This is why it’s important for a successful, clever Product Manager to ensure that they have a view not only of the “product” that they’re specifically working on creating requirements, specs, and user stories for, but the “whole product” that the company is selling. If you silo yourself to only viewing the “product” as the particular piece of technology or a specific solution to a specific set of problems, you’ll inevitably be missing the bigger picture of how people use your product, why they use your product, and most importantly where your “product” fails to meet the needs of the users — and where those gaps are being filled in by others, either internal to your company or external groups making money where you should be focusing product.
What is the “Whole Product?”
The term “whole product” as I’m using it here originally stems from Geoffrey Moore’s Crossing the Chasm, where he talks about the importance of ensuring that everyone who is working to support the product understand (1) what that product is, and (2) how what they’re doing is affecting the success of the product. It’s a very important piece in the book to understand how you can push your product across the “chasm” from early adopters into the mainstream, but I think it’s actually far more important than that in general.
Let’s start by talking about what most people think of when they think of a “product” in general. For most Product Managers (and indeed, most companies), the “product” is the thing that ships. It’s the thing that the developers build, that the marketeers write their copy for, that the sales people spin to their prospects, and that the support team takes calls for.
But this is a very limiting view of the “product” – it narrows it down to the bits and bytes, or the physical device, or the “thing” that people are using — but it seriously neglects the other parts of the “product” that are just as important as the “thing” itself. For example, looking at the list above, you’ve got marketing efforts that are required for the success of the product; you’ve got sales efforts required for success; you’ve probably got implementation teams, service teams, support teams, escalation teams, documentation teams, finance teams, and any number of people whose every day job contributes to the success of the product.
And that’s what the “whole product” concept tries to take into account. The “whole product” is the entire set of capabilities that your company provides which result in the success of the product. What the implementation team does to bring people on-board is part of the “whole product;” what the support team does to help customers who are experiencing problems is part of the “whole product;” how your marketing and sales people talk to the customer and prospect about your offering is part of the “whole product”. To understand the “whole product” is to have a holistic comprehension about every part of the company that contributes to the success of what you offer your customers, as well as an understanding of not only what your product actually delivers, but what your customers and prospects expect it to deliver.
Understanding the “whole product” means having a holistic comprehension about every part of the company that contributes to the success of your engagement with customers.
Why is it Important to Know Your “Whole Product”?
The Whole Product approach is another angle on the traditional “not seeing the forest for the trees” problem that many Product Managers face on a daily basis. Because Product Managers are caught up in a constant tension of balancing strategic planning and tactical delivery, we usually wind up leaning one way or the other. Taking a view of the “whole product,” however, provides us with an ideal method to balance out those strategic and tactical needs, as we can look across everything that drives value and determine what is working, what is not working, and what steps we can take to optimize and improve the overall product offering, and not just the bits and bytes that ship out and comprise what we commonly think of as a “product.”
For example, in many enterprise B2B scenarios, there are several different teams who interact with the customer before they ever actually start using the product. These may be sales engineers, or implementation teams, or account managers, or integration teams — and what they do (and how they do it) has a major impact on the overall experience of your customers and end users. And under a traditional product focus, the Product Manager may have only limited insight into what these teams do — relegated to an order-taker when something goes wrong or when the customer speaks through one of these teams. However, under a “whole product” approach, what these teams do, how they do them, and how they work with customers becomes an integral part of the Product Managers understanding — and they become part of the product, not just an ancillary set of services that someone else manages. Their needs become part of the product roadmap; streamlining their processes becomes just as important as providing a good UX within the “product” itself (sometimes, more so). By taking a holistic view of what the “product” really is, what provides value to the customer, and what steps can be taken to improve the overall customer experience, the company itself becomes more successful.
By taking a holistic view of what the “product” really is, what provides value to the customer, and what steps can be taken to improve the overall customer experience, the company itself becomes more successful.
Steps to Ensure “Whole Product” Conversations
The surest way to ensure that you are having conversations about the “whole product” is to establish a weekly or bi-monthly meeting where representatives from every division within your organization are present. In many ways, this meeting is much like a daily “scrum” meeting that developers often use in Agile practices. It’s an opportunity for people to talk about what their teams have done since the last meeting, what they’re planning to do going forward, and raise any questions or concerns that they may have regarding what others are doing.
Here’s a starting setup for such a meeting — make sure that you’re revisiting your cadence and the content so that people are getting valuable information. Absolutely nothing will kill a meeting like this as quickly as people seeing it as a waste of time.
- “Lightning Round” – One representative from each team talks briefly about what they’ve done since the last meeting, any ongoing projects that are in-flight, and any new plans that may start before the next meeting. This must be no more than a minute per team, to ensure speed and interest; questions or concerns should be noted down and discussed later.
- “Open Issues” – The Product Manager should keep an ongoing list of questions or concerns from prior meetings, and provide updates on the status of those questions or concerns at each meeting. This reinforces that someone is listening, and ensures that there is some action and follow-up when there are open questions.
- “Product Review” – The Product Manager should discuss briefly what the development teams are working on, any changes in schedule or scope, and any upcoming reviews or opportunities for feedback or input. This ensures that the “roadmap” is given constant visibility for feedback and comment, rather than randomization.
- “Open Forum” – This is the opportunity for everyone to ask the other team representatives questions or to raise concerns about any conflicts or cross-work that may be going on. The Product Manager should lead this discussion and take copious notes, taking any lengthy discussions out of the meeting and ensuring follow-up and answers whenever possible.
- “Recap” – The Product Manager should provide a brief recap of the discussions, noting any further action that will be taken or follow-up that may be needed in between meetings. This closes the meeting, and should be the primary content of a follow-on email containing notes and action items, sent to everyone involved (present for the meeting or not).
End-to-end, you don’t want this meeting to be any longer than 60 minutes, and if you can narrow it down by focus and facilitation to 30 minutes, people will love you for it. It is also important that this meeting happen when it’s scheduled to – this cannot be a jumping meeting; every team is expected to send a representative, and failure to do so doesn’t alter the rest of the discussion or process — regardless of who’s not there. This isn’t a meeting that gets rescheduled at the CEO’s whim, or at the request of the VP of Sales. The meeting happens, and the people who are there have their discussions. This needs to be a meeting that’s important enough for others to change their schedule around.
