As we discussed in our first article on B2B enterprise apps, to develop a successful app for the enterprise market, you’ll need to build long-term relationships with your customers—these are definitely not one-off downloads. In the discovery phase, you focused on identifying the two important enterprise customer types—the end user, and the check-writer—and gathering data from both types of customers to understand their pain points, which allowed you to put together a solid plan.
Now you’re ready to build the first version of your product, or your proof of concept, which will allow you to further validate the market. Will your idea work? Will it meet your customers’ needs? To find out, you'll need to convince at least one of your established contacts to work with you more closely, converting that company into a reference customer, and gathering their insight as you build a proof of concept and begin to iterate.
Find Your Reference Customers
You talked to a lot of potential customers as you researched end-user and check-writer pain points. During that process, you likely met a few people who were as excited about your solution as you are. These are the folks to reach out to about the organization becoming a reference customer. Your ideal reference customer is an influencer in the industry you’re serving who has fairly typical needs around your solution and is willing to pilot your app. During the pilot, you will fine-tune the app based on their feedback. Once it’s to their liking, these organizations will serve as references to help you scale your solution to others in the industry.
Ideas to consider:
- Look for a reference customer—more could get messy if you need to build out specific features for any of them.
- Offer your app for a nominal fee in exchange for their help and feedback.
- Plan for the pilot to last 3-6 months to gain the most useful feedback.
Leverage Your Champions
Once an organization has agreed to the pilot, you will need to gather some additional requirements before you start to build. Engage your champion(s) within the organization to help you determine the minimum barriers to entry—companywide or industry requirements, such as data security, compliance, and compatibility that aren’t exactly features of your app, but need to be built in for the company to be able to adopt it. Your champions can help you answer these key questions:
Who else needs to approve it?
Your main client will connect you to additional decision makers within their company, such as legal, IT, cross-functional partners, and even additional off-label users who might interact with the product or use it in different ways. What will they be looking for? What role will they play in the final product or purchasing decision?
What matters to these additional stakeholders?
From your research in phase 1, you probably have a good understanding of which key features you should include in your first iteration, and which can wait. (If you don’t, work with the end-user and check-writer customers in this organization to find out.) At this point, you need to also identify any requirements these additional stakeholders might have. Are there specific rules or systems that must be used for data security? Does the organization have compliance needs that absolutely must be addressed in the proof of concept before they’ll even consider it?
What objections might they have?
A corollary to the above—be sure to listen for what objections each stakeholder might have. Does the legal department have concerns about how the product will be branded? Is IT worried about compatibility? These needs of various stakeholders may well be in conflict; be prepared to keep pressing for a solution—and don’t be shy about leveraging your champion, with her inside knowledge of the organizational culture and requirements—to help.
POC vs MVP—What’s the Difference?
Once you’ve deepened your relationship with your stakeholders and have a plan for the minimum required feature set, you're ready to build a proof of concept. But what exactly is that, and how is it different from a minimum viable product, or MVP?
If you’re coming from the B2C or consumer market, the MVP is a very familiar idea. An MVP is a product that contains enough of the key features to fulfill the concept and to function, but is streamlined and minimized for the quickest possible build—so you can start getting real feedback from real customers as soon as possible.
A proof of concept, or POC, operates under a similar theory, with a focus on speed and iteration. However, because you're now working with an enterprise B2B client, even your first simple prototype will need to be a lot more baked. There's a lot more on the line, in terms of investment, and you’ll need to be a lot more intentional about the features that are included.
Let’s consider the example we used in the last enterprise B2B article, of an e-commerce portal for marketers to help them manage inventory, maintain presentations, and increase transactions. In building the POC, it's likely that you'll want to not only demonstrate key functionality, such as updating product content and tracking real-time availability, you may also need to test the connection to the existing POS system, or include metadata to get the analytics team on board.
A Word About Custom Features
In the consumer app world, you’d never create a specific feature set to serve the needs of a single customer. But in the enterprise world, you might need to do just that. Imagine that one of the biggest retailers in the world wanted to use your e-commerce portal—but required integration with a legacy system not used by the rest of the industry. Satisfying this giant might be your ticket to industrywide adoption, making the extra work of the custom build well worth it in the end.
Iterate Until You Have a Product Your Reference Customer Loves
Just like with an MVP, your proof of concept is just the beginning. Iteration is key. Your product has moved beyond theory and it's time for you, and your customers, to further refine your needs and requirements. Don't be surprised if some of your features change pretty significantly once they're implemented and tested—that's why the proof of concept phase is so important. Continue to work closely with your champion, and all of the related stakeholders, to create a product that truly serves your enterprise customers’ many needs.