There's no question that it's hard enough just trying to come up with a product that your customers love and your engineers can build and deliver. Many products never get to this point.
However, the truth is this is not enough. The solution must also work for your business. And I will warn you now that this is often much more difficult than it sounds.
Many product managers confess to me that this is the least favorite part of their job. While I understand that, I also explain to them that this is often what separates the good product managers from the great ones, and that more than anything else, this is what is really meant by being the CEO of the product.
Building a business is always hard. You must have a business model that's viable. The costs to produce, market and sell your product must be sufficiently less than the revenue your product generates. You must operate within the laws of the countries you sell in. You must hold up your end of business agreements and partnerships. Your product must fit within the brand promise of your company's other offerings.
This is what is really meant by being the CEO of the product.
You need to help protect your company's revenue, reputation, employees, and customers you've worked so hard to earn.
In this chapter, I name the main stakeholders in a tech‐powered product company, discuss their typical concerns and constraints, and explain how the product manager would test business viability with each area.
While this is a very common list, and most or all of these areas probably apply to your products, it is also very common that any company will have one or more special stakeholders that are unique to the business. Just because it's not listed below does not mean it's not absolutely critical for you to deal with.
The last thing you want to have happen is that your team moves forward and takes the time to commercialize the solution and deliver a shippable product, only to find out that you can't ship because you are violating one of these constraints. Make no mistake about it, when that happens, it's on the product manager. It is your job to ensure that you understand each of the relevant constraints, and take positive action to work within them.
We've already discussed product marketing, which we view more as a member of the product team than as a stakeholder. But, more generally, marketing cares about enabling sales, they care about the brand and reputation of the company, and they care about market competitiveness and differentiation. Marketing needs the resulting products to be relevant and compelling, and work with the go‐to market channels. So, anything that you're considering that puts those at risk will be a major concern.
If what you are proposing to build could impact the sales channel, the major marketing programs, or is potentially outside of the brand promise (the range of things your customers expect from your company), then you'll want to discuss this with marketing and show them prototypes of what you are proposing before you consider building anything. Work with them to find ways to address their concerns.
If your company has a direct sales organization or an advertising sales organization, then this has a very big impact on the product organization. Successful products typically need to be designed around the strengths and limitations of the sales channel.
For example, a direct sales channel is very expensive, and this requires a high‐value product and price point. Or, you may have built up a sales channel with a certain set of skills, and if your new product requires a very different set of skills and knowledge, your sales force may completely reject the product.
If what you are proposing would represent a departure from what the sales channel has proven their ability to sell, sit down with the sales leadership and show them what you are proposing before you build anything, and see if together you can figure out a way to effectively sell this.
Some tech companies have what's referred to as a high‐touch model of helping their customers, and some have a low‐touch model. You need to understand what your company's customer success strategy is, and you need to ensure that your products are aligned with that strategy.
Again, if you are proposing something that would represent a change, you'll want to sit down with leadership and discuss the options.
As a side note, if you have a high‐touch service model, these people are exceptionally helpful for product insights and prototype testing.
Finance often represents several different constraints and considerations, not the least of which is whether you can afford to build, sell, and operate your new product. But, business analytics and reporting are often in finance, and investor relations and other concerns may bring their own set of constraints.
If there are cost issues involved, sitting down with someone in finance and modeling the costs will be critical to demonstrating to leadership that you have worked out a viable approach.
For many tech‐powered companies, especially those that are working hard to disrupt markets, legal can play a very significant role. Privacy concerns, compliance concerns, intellectual property, and competitive issues are all common constraints related to legal. You can save yourself a whole lot of time and grief by sitting down early with someone from your legal team and discussing with them what you are proposing and whether they anticipate any issues or areas you should be aware of.
Most businesses have some number of close business relationships with partners of various types, usually with a contract behind each that has a defined set of commitments and constraints. Sometimes these agreements can cripple your company's ability to compete. Sometimes they are a huge win. In either case, you need to understand the impact of these relationships on your products and what you are proposing to do.
We would normally think of security not as a stakeholder, but more as an integral part of the engineering organization and hence a part of the product team. However, the issues involving security are so important for so many technology‐powered companies that I think it's useful to call the area out. If you are proposing anything at all remotely related to security, you will probably want to bring your tech lead and sit down with the security leadership early to discuss the ideas and how you will address their concerns.
Of course, with every company there is some CEO or general manager that is responsible for the business unit. They are very likely aware of all these constraints, and normally they are worried about them. And if the product manager is not also aware of the issues, or does not have a plan for dealing with them, the exec is not going to trust the product manager or product team.
It doesn't take long for a CEO to figure out whether a product manager has done her homework and understands the different aspects of the business.
Testing business viability means making sure that the product solution that your team is proposing will work within the constraints of each of these areas. For those stakeholders that are impacted, it's important that they have a chance to review the proposal and ensure their concerns have been addressed.
Throughout this book, I have talked about “showing the prototype.” In truth, there are three very different techniques for showing the prototype, and you have to be careful to use the right technique for the right situation.
A user test is when we test our product ideas on real users and customers. It is a qualitative usability and value‐testing technique, and we let the user drive. The purpose is to test the usability and value of the prototype or product.
A product demo is when you sell your product to prospective users and customers, or evangelize your product across your company. This is a sales or persuasive tool. Product marketing usually creates a carefully scripted product demo, but the product manager will occasionally be asked to give the product demo—especially with high‐value customers or execs. In this case, the product manager does the driving. The purpose is to show off the value of the prototype or product.
There are three very different techniques for showing the prototype, and you have to be careful to use the right technique for the right situation.
A walkthrough is when you show your prototype to a stakeholder and you want to make sure they see and note absolutely everything that might be a concern. The purpose is to give the stakeholder every opportunity to spot a problem. The product manager usually drives, but if the stakeholder would like to play with the prototype we are happy to let them. You are not trying to sell them anything, you're not trying to test on them, and you're definitely not trying to hide anything from them.
I have seen many inexperienced product managers do a walkthrough with a prospective customer when they should have prepared a product demo. Or another really common rookie mistake is to do a product demo during a user test, and then ask the user what they think.
Be sure to be clear about whether you're doing a user test, a product demo, or a walkthrough. And, be sure you're skilled in how to do all three.