Beyond product-market fit: putting market into product

Another entry in a blog series on the key questions that climate tech companies should be asking as part of their business, product and market strategy. 

This blog focuses on the following questions: what product, who is going to buy it, who is going to use it, and how to deliver it. The key is to go beyond the relatively linear question of having a product and finding the right market to sell to. Instead, product and market need to be thought through holistically and simultaneously, as part of the product design process, in order to achieve true product-market fit.

Market and product are intertwined

Many climate tech companies are starting with a technology in hand, and then trying to think about product-market fit. But the notion of product-market fit is itself backwards. It needs to be market-product-market. Even if you have a technology in hand, to create a commercial product, you need to start your thinking with the market, figure out the key product feature requirements (which is not the same thing as the technology), then figure out how to get the product to market. And then circle back and incorporate the go-to-market into the actual product design. Then you build the actual product. Don’t build the product and then try to figure out go-to-market. Why?

Increasingly, important aspects of go-to-market are instantiated in the product itself. Products where there can be a network effect such as collaboration tools can build in methods and incentives to invite others. Complex products that can take a while to ramp on (thus risking low adoption and high churn/abandonment) can build in first time user walkthroughs and starter kits. Telemetry can be built into products so that companies can detect usage patterns, creating a feedback loop for both product design and for selling.

Unfortunately, “product” (i.e. engineering and product management) and “go-to-market” (i.e. marketing, sales and business development) are separate functions in most companies– even in tiny startups with a handful of people. That mentality is a hindrance as product and market are increasingly intertwined, and it’s important to look at market-product-market holistically, before the product is fully built. 

Understanding of users and buyers is key in product design

In B2B, there isn’t an individual buyer, there are buying teams, and users often aren’t in the decision making seat. Typically, there are different people/roles including:

Core buying team: folks who need/want the product

• the hands-on user: the person who is going to use the product on a day-to-day basis

• the administrator: the person who sets up and maintains the product for the hands-on users

• the champion: the person (often a hands-on user or administrator) who is a big fan of the product and strongly and vocally advocates for it

• the decision maker:  the person who makes the decision on whether to buy the product or not, and shepherds the decision through the company’s internal approval and procurement processes. Often the manager of teams of hands-on users and/or administrators.

• the economic sponsor: the person who owns the budget for the purchase. Often the decision maker’s boss, or one level higher. May be the same as the decision maker, especially for smaller ticket purchases.

Extended buying team: folks with veto power

• the infosec evaluator: the person who evaluates the technology to ensure it meets company information security policies and compliance requirements

• the tech evaluator: the person who evaluates the technology to ensure it meets with the organization’s technology standards and policies for reliability, scalability, etc. May be the same person as the infosec evaluator.

• the procurement manager: the person in finance who negotiates with vendors and tries to get the best deal

So amongst all these people, who do you design your product for? In the days of traditional, top-down relationship selling, companies focused on putting in features the decision maker and economic sponsor cared about most. If the product was difficult to use or administer, that was tough luck for those hands-on folks but they had to live with what their bosses dictated.

Nowadays, product-led approaches are becoming dominant. You design the product to be as easily and quickly adopted by hands-on users as possible (ideally for free for at least a limited time to maximize the number of users), with a maniacal focus on providing them with immediate, tangible benefits. Some of the users will turn into champions, spread usage within a company, and then make it inevitable that decision makers see the value of the product and authorize a formal or at-scale purchase. It’s still wise to put in some features the decision makers and economic sponsors will care about (often analytics/dashboards that provide visibility/control and also justify the investment.) And you need to tick the key checkboxes for the infosec and tech evaluators, or you’ll get vetoed. But those are lower priority than taking out as much friction as possible for hands-on users to get to the valuable result they need.

Of course the devil is in the details, but the point here is that you can’t design a product unless you have a strong sense of who the users and buyers are– i.e. persona research. B2B startups know they are selling to a complex team, but too often wing it instead of really figuring out the details. They may find themselves wasting time on the wrong features and capabilities, while missing out on key ones that would lead to real adoption.

Delivery can’t be an afterthought

Just as buyer personas need to guide product design, how the product will be sold and delivered also needs to be considered upfront. Delivering a product as a service vs. as something that the buyer owns can greatly affect the product design and architecture. If your product is going to be sold or delivered through a third party channel (such as a dealer or a marketplace), there are often product requirements to meet that channel’s policies and to get buyer attention in a crowded space. Even how you price the product may need to be designed in. For example, if you have usage-based pricing, you will need the ability to meter, report and bill on usage.

These are just some of the delivery considerations that need to be designed into the product, rather than treated as an afterthought.

How to do all this and still be agile

Okay, so as a startup you might be thinking how the heck do you do all this and stay agile, knowing that your first attempts at product and delivery will probably be off the mark, and ongoing adjustments will be needed?

There’s an art and a science to this that can’t be boiled down into a blog. But a few tips: 

• If you ask the right questions, you can do persona and requirements research very quickly– in weeks. It requires a semi-guided discussion and careful listening, but it can be fast and high fidelity.

• Research and validate designs, not built product. You can get a lot of insight by shopping around high fidelity design concepts, long before you invest the time and effort to build product. And do fast iterations on these design concepts while you’re doing your research.

• Architect in flexibility where you can. Whether it’s APIs and microservices or modular components, investing in a reasonable amount of flexibility in your product architecture will make pivoting in response to the market a lot easier.