When delivering new products to early customers, you need to strike a balance between speed to market and enough functionality to deliver real value. Many Product teams approach speed to market with a “minimum viable product” or MVP mentality. Although the idea of an MVP sounds appealing, I’ve found a fundamental problem with MVPs in B2B innovation:
MVPs, by definition, focus on the minimum functionality possible, but in reality, teams use MVPs as an excuse to cut corners and avoid implementing important functionality that can make or break an enterprise product.
Cutting corners and delivering a half-baked product might work in B2C, but it always backfires in B2B, whether it’s Enterprise Software or IoT. The reason is that working with early customers is all about delivering value and building trust. Instead of using the term MVP, I advocate calling them prototypes.
Your prototype might not be full-features, but it is still a working, usable piece of technology that enterprise customers can use and get value from.
When you are going into a pilot program with early customers, your early adopters expect a working prototype with enough functionality to deliver value AND the required functionality to perform within an enterprise environment.
According to the B2B Innovator’s Map, you are here:
8 Critical Considerations to Ensure Success with Early Customers
If you want to build trust with your early customers AND maximize your chances of delivering value during your early pilot programs, you must ensure your product meets the basic requirements in these eight areas:
These areas will take time, but you shouldn’t see them as time-wasters. Instead, think of them as necessary for your product to even be considered in a B2B setting. Without attention to these areas, most companies will not even entertain engaging in a pilot program with you. So think of these items as door openers and risk mitigators you must tackle early on.
Complying with regulation means that your product doesn’t break the law. It sounds easy, but complying with regulations can be much harder than it seems. For example, your product might need to comply with regulations around data, safety, and cybersecurity—or industry-specific regulations such as those in the healthcare or energy industry.
Regulations vary by industry and by geography—not to mention they change all the time. Therefore, it’s essential to seek expert advice. If you are part of an established company, involve your legal and compliance teams. They need to understand your goals and roadmap to make sure you won’t expose the company to any legal risks. On the other hand, if you
are part of a startup or smaller company that doesn’t have a compliance team, seek expert advice from third parties or consultants.
These expert reviews will take time and money, but they are necessary to ensure your product is compliant and won’t get you into legal trouble. When engaging with early adopters, don’t be surprised if their procurement team asks you to demonstrate compliance with the applicable industry rules and regulations. It’s a standard procedure, and you need to be prepared to meet any required rules, regulations, and even certifications.
Recommended podcast episode: How policy can kill your product, a perspective from the Electric Vehicle Industry
During your pilot, delivering a stable product is a must. Nothing kills customer trust and momentum faster than a buggy, unreliable product.
Early adopters are willing to try out unproven technology to solve a burning pain, but that doesn’t mean they are willing to put up with an unstable solution crashing all the time or returning incorrect results. Therefore, your product must be stable to instill confidence in your customers.
It’s important not to confuse stability with scalability. These concepts are independent of each other: you can have a stable solution that doesn’t scale or a large-scale solution that’s not stable. Both scalability and stability take a significant amount of engineering resources, so at this stage of the B2B Innovation Journey, aim for a stable solution even if it doesn’t scale to large numbers of users or cannot process large amounts of data.
You don’t need a product that scales at this stage. Instead, use those resources to iterate quickly on value-added features that can help you gain further evidence that your product can deliver on its promise. Once you deliver value to your first ten pilot customers, you’ll be able to plan your next steps, and at that point, you can decide to invest in scaling your solution.
Cybersecurity is one of the first areas that gets pushed aside and labeled as “to figure out later.” But unfortunately, later never comes, and that is why there are so many vulnerable products on the market.
Cybersecurity refers to your product’s ability to deflect any intrusions and ensure no unwanted actor will harm the product, its users, and any of its data. Building secure solutions is not a one-and-done deal. Instead, it is a constant process throughout your product’s lifecycle.
Your product will be as strong as the weakest of its components. I recommend using your Solution Diagram (as described in my book) as a conversation starter with your team. Discuss how you are securing every component and what the plan is to secure any weak links.
Cybersecurity can be a door opener or a blocker for you to win pilot projects. When negotiating a pilot project with your Champion, her procurement and IT teams will want to understand how your product tackles security. They’ll scrutinize what you have implemented, how you’ve implemented it, and how you will respond in the event of a security breach. Your team must have clear answers to these questions; other- wise, you are not likely to get that pilot contract.
In short, your team needs to focus on implementing security best practices from the very beginning. Failing to do so can have big reputation and liability risks for your company, plus it will significantly affect your chances to close pilot projects.
Recommended podcast episode: Cybersecurity in Industry 4.0 – the Good, the Bad, and the Ugly.
Safety is another area that is often overlooked. Safety refers to how likely your product is to harm people or property. Safety concerns are more significant when your solution interacts with hardware because now you have a link to the physical world, and you can instill physical harm on people or property.
When I coach leaders about safety, the conversation often goes toward extreme examples, such as self-driving vehicles or drones. But safety issues can occur in more straightforward products as well. I’ve seen it all firsthand. I’ve seen industrial computers catch on fire, circuit boards explode, and workers lose their fingers to rotating machinery run by faulty software.
Depending on your industry, you might need to comply with safety regulations. In those cases, you’ll need to certify your product with a third-party organization before it’s deemed safe for deployment, even for a pilot. But even if your industry doesn’t have those regulations, it’s essential to ensure that your early solution is as safe as possible. The last thing you want is your prototype burning down a customer warehouse or triggering the fire alarm at a hospital. Companies rarely recover from such a big reputational hit.
You must put extra emphasis on protecting the privacy of your customers and your company. The best way to approach privacy is with transparency. From the very beginning, make it very clear to your customer and your company what data you plan to collect, how you will use that data, and who has access to that data inside your organization. Disclosing your privacy practices is not only the right thing to do, but it’s very likely something you’ll need to do as part of negotiating a pilot contract.
Now, contractual language aside, make sure that your product delivers on your privacy promises. That means allocating time in your development lifecycle to test the areas where privacy could be compromised. I’ve seen situations where the privacy violations were not due to malice or lack of transparency but instead resulted from software bugs that allowed unauthorized users to access data from other users, competitors, and even your own company. Like security and safety, make sure you test out various privacy scenarios to ensure you comply with what you are promising.
As sustainability gets more ingrained in your customers’ day-to-day operations, an increasing number of companies will look at sustainability as an essential criteria for vendor selection. If your product doesn’t meet your customers’
sustainability requirements, you won’t be considered even for an early pilot. Plain and simple.
The key areas that your customer’s sustainability and corporate responsibility department will care about include:
- How energy-hungry is your solution?
- Are you powering your solution with clean energy?
- How much waste does your solution create ( e.g., packaging, exhausts, end-of-life recycling)?
Creating sustainable products is usually a supply chain challenge. Therefore, as you choose your technology partners, you should evaluate them in the same way that your customers will evaluate you. For example, you should choose cloud infrastructure from companies that power their data centers with 100 percent renewables or choose your packaging from vendors that use only recycled materials.
Building a sustainable product is the right thing to do for the environment and society. But it can also be another differentiator that will open doors for your pilot and may become a baseline requirement for customers even to consider you as a vendor. So start incorporating sustainable development practices early in your product, and you’ll be ahead of the game.
Recommended reading: How to Build Sustainable IoT Products
I refer to product ethics as the responsibility you have to ensure your product avoids discrimination or bias, cannot be easily weaponized, and cannot be used in nefarious ways.
Common examples include the disinformation engines in social media platforms or the many cases of IoT devices used to spy on people. Make sure you work with your team to understand any scenario where your product might run into ethics issues and create a plan to address it.
More and more companies are placing importance on product ethics, so don’t be surprised if your Champion asks you about the steps you are taking to ensure your product is as ethical as possible.
Enterprise software does not live in a vacuum. Instead, your solution will need to integrate with many other systems already in use by your customer. To ensure interoperability, your product must implement the standards that are common in your target market.
There are technology standards that go across multiple industries, such as using RESTful APIs for cloud-based solutions. On the other hand, there are many standards that are unique to each industry, such as CAN bus in the automotive industry or BACnet in the building industry.
The takeaway is that you need to work with industry SMEs to understand the standards of your target market. It doesn’t matter if your engineering team comes up with a technologically superior approach. If you are to play in a particular industry, you need to play by that industry’s rules.
Recommended podcast episode: Is 5G Worth It?
The Bottom Line
These eight areas will be present throughout your product’s life- cycle, so start incorporating them early on. They will help you build trust and will increase your chances of delivering value to your early customers.
Also, keep in mind that these eight areas require time, money, and multi-department collaboration. Therefore, make sure you seek constant support from your Advisory Board and leaders from various departments, including engineering, legal, compliance, corporate responsibility, cybersecurity, etc.