Pledge To Customers
An Empowered Product Team’s Pledge To Customers
As a company moves from sales-driven feature teams to empowered product teams, there are some fairly significant changes to how the product teams need to interact with customers.
Most of those changes are not directly visible to the customers, as they involve how product teams do their daily work to discover and deliver solutions.
But as most readers of these articles know, direct and frequent interaction between the product team and the actual users and customers is at the core of how strong product teams work.
I like to encourage product teams to explain their intentions as they begin to interact directly and intensely with users and customers, as this change may be very different from the customer’s perspective as well.
Realize most customers are used to just dictating features they believe they need to their sales person, and then they expect to see their features on a product roadmap soon, with a date they can start planning towards.
Although it is also likely that the customers have already begun to lose confidence in the company’s ability to deliver those features on the promised dates. At some point, a frustrated customer may seek another company’s product. But if they believe in the product vision, they will usually try to hold on as long as they can.
So most customers are open to the idea of a change in the dynamics, but only if they believe that they’re more likely to get their needs met, rather than less likely.
These pledges are intended to describe what customers can expect from an empowered product team, and the reasons behind the differences:
PROMISES
Our product team pledges to no longer promise a date or a deliverable until and unless we truly understand what will be required to deliver on that promise. This is very different than how we have been working, and this change has several significant implications:
- The product team making that promise will need to engage directly with the users and customers in order to truly understand what will be necessary to succeed. Note that companies often have well-meaning people assigned to manage relationships with customers, just as customers often have well-meaning people assigned to manage relationships with providers, but these proxies – whether from our company or the customer – are not sufficient. Direct access between the product team and actual users is essential, and a prerequisite to any commitments.
- The only people that can make a promise for a product deliverable is the product team that will be responsible for delivering on this promise. Not the company’s executives, not sales, not marketing, not customer success, not delivery managers. The promise must come from the people that need to fulfill that promise.
- The product team will not make a promise until and unless they have conducted enough product discovery work to understand what is truly required, and whether that solution provided will be effective for the customer. Normally this means one or more prototypes to address the specific risks. Once the needs are understood, the team will also factor in other work and commitments, before they are ready to make any promise. We call these promises high-integrity commitments. And the product teams that make these commitments pledges to do everything humanly possible to deliver on these commitments once made.
- The product team may need to remind the customer that as a commercial product company, their job is to not only come up with a solution that the customer believes is effective, but they must ensure that this same solution will work for other customers as well. This is the essential difference between a custom solution provider, and a commercial product company. What this means in practice is that sometimes the specific solution that the customer has in mind is not general enough to work for other customers, and so the product team will need to explore alternative approaches. Most of the time this is solvable and results in a better solution for all involved. But if it were to turn out that the necessary solution would only work in a single customer’s environment, and the customer understands that they would not have the benefits of our ongoing innovation and service, then normally the product team would instead direct the customer to a custom-solution provider.
PRODUCT DISCOVERY
The purpose of product discovery is to come up with an effective solution to our customer’s problems. Our product team pledges to constantly strive to discover solutions that our customers love, yet work for our business. This means three important things:
- First and foremost, the solution must solve the customer’s problem/address the specific customer needs. This means the solution must be both valuable to the customer, and usable by their users.
- Second, the solution must be technically feasible. The product team needs to have the enabling technology, the necessary skills on the product team, and the necessary time to develop that solution.
- Finally, the solution must also be viable for our company. We must be able to fund the solution, effectively monetize the solution, market, sell and service the solution, and the solution must be compliant with any industry, legal, or privacy regulations or constraints.
In order to do this, the product team has a cross-functional set of skills in product management, product design and product engineering. All three of these core skills need to engage directly with users and customers to both deeply understand the problem that needs to be solved, and to test out potential solutions.
For the majority of our direct customer interactions, our product team is focusing on both understanding the customer’s problem, and determining if we have come up with a valuable, usable, feasible and viable solution.
As such, most of the direct interactions between the product team and the customer involve interviewing the different users, and testing prototypes of solutions with those users.
PRODUCT DELIVERY
Once our product team has discovered and developed the necessary solutions, we understand we have additional obligations in order to appropriately serve our customers:
- We pledge to effectively test our solutions, which means two different activities. First, we will test that the new capability works as expected. Second, we will test that the new capability does not inadvertently introduce any problems elsewhere. These are called regressions, and while we acknowledge that preventing regressions is difficult, and sometimes they occur despite best efforts, we also acknowledge we have a responsibility to ensure that new capabilities do not come along with unexpected problems.
- We understand that you urgently need the solutions we are building, but we also acknowledge that you have your own jobs to do, and spending time re-certifying our product, and re-learning and re-training on our product, is not something you want to do, nor should you be required to do. We pledge to always be sensitive to the cost of incorporating our new capabilities into your daily use, and we will use modern design and deployment techniques to smooth adoption whenever possible.
- Finally, we know we can’t realistically promise that we will never make mistakes. However, we can promise to use best practices and best efforts to minimize those mistakes, and most importantly, we can and do pledge that when mistakes are made, we will do everything in our power to quickly and competently correct the issue, and then to analyze how we can avoid that problem in the future.
HAPPY REFERENCEABLE CUSTOMERS
Our product team’s highest order goal is to do everything we can to get each of our customers to the point where they are effectively using our products every day to do important and meaningful work, and that our customers love and value our products so much that they happily share their experience with others.
This is how we feel about our favorite products, and we pledge to work everyday for our customers to feel that way about our products.