Why building for enterprises may seem like feeding an elephant?

Understanding how B2B product management is a different ball game altogether

Published in

Product Coalition

11 min readMar 26, 2019

Product folks who have worked on the early stage enterprise products may relate with the title. Building an enterprise product is a whole lot different from building a consumer product. Much of this difference can be attributed to the buying behavior of the enterprises and the complexities arising out of the vastness of the enterprise process you are trying to fix. Let’s look at the differences bit by bit.

Who are we building for?

Building a consumer product

If you are building a consumer product, more likely than not, you are trying to address a very specific need of a set of individuals.

You identify a gap in the market which you hypothesize as an unsolved problem. You work on customer discovery with the potential target segment you believe might be facing this problem to validate your hypothesis, propose your solution to the problem and try to figure out if there is a problem-solution fit. Once the problem-solution fit has been identified and your proposed minimum-viable product (MVP) inspires enough confidence in you to move forward to the next step, you start building the product and look for a product-market fit (PMF) — the process called customer validation. A product-market fit with a scalable business model sets the way forward for you to continuously improve your offering to strengthen the value proposition for your consumers.

The most critical part in the entire process is to ‘understand the consumer’. You can not build a product on day zero that makes everyone happy. If you are trying to do that, you are heading for a disaster. You need to be insanely obsessed about understanding your customers. This will help you refine the segment you are targeting. If of the ten early adopters, four are incredibly happy with your MVP and are passionate to spread the word about it, you need to understand what is it that differentiates these four from the remaining. You are going to build for these users. You are going to look for more of such users. You’ll aim to enhance the value for these users.

So you need to understand what do they do. How does their day look like? What facet of their life is eased out the most by your product? What emotional, physiological, psychological or financial needs of these users are met by your product? What makes them willing to pay for your product? Once you have understood your customers — you have chalked out your target persona.

This target persona, sets the basis for your product decision making. You start eliminating requests and feedbacks that do not serve this persona and attempt to solve the validated problem that best maximizes value for these users. This may not be all that simple two things are to be observed here:

You have a lot of creative freedom to solve the problem identified. The users need the easiest solution, regardless how you solve it.
The cost of missing out on the users who do not concur with the solution is not very high. You still have a large enough base to acquire (assuming yours is not a very very niche offering).

Building an Enterprise Product

Note that I’ve used the terms ‘user’ and ‘customer’ interchangeably in the above section. This is because, for most for B2C products, the user is also the customer. Technically, a customer is the one who pays for your product and a user is the one who eventually uses the product. For B2C products, these two people are usually the same and that’s why these products are also called consumer products.

While the basic principles for customer discovery, customer validation and scaling remain same for enterprise products also, the customer is not always the user. Take Intuit’s accounting product Quickbooks, for example. The users for this accounting software are the finance and accounting professionals in a company, the customer is the ‘Enterprise’ paying for this product. And enterprise is not an individual. So, the purchase decision is usually taken by a set of stakeholders, each having different priorities.

The representatives from technology team in the buying process will seek to evaluate the product on technical aspects like security, scalability and reliability (uptime), the representatives from finance team will evaluate the product primarily from financial compliance and audit point of view. Likewise, the stakeholders from different departments will evaluate the product for different objectives they have to meet. And so, it becomes equally necessary to ‘understand and serve these stakeholders’, in addition to ‘understanding and serving the users’. Continuously understanding, evaluating, filtering and fulfilling the needs of so many stakeholders at a time and not getting carried away to build a customized piece of software for a single organization, may sometimes feel like ‘feeding an elephant’.

Why this complexity?

It’s natural for anyone without an understanding of business buying process to ask, ‘Why do businesses have so many stakeholders involved in the decision? Doesn’t it make the process complicated and dilute the accountability?’ Well, it does. But it can’t be done away with.

Here’s the reason why.

While building consumer products we are looking to solve a problem our prospects are facing. These problem are usually unmet one-off needs. Think of any eCommerce platform, for example. Amazon.com came into existence for ease of discovery and purchase of books. Uber came into existence for ease of access to cabs. Similarly, most of the consumer products start with a single need or pain point. These products are mostly point solutions — addressing a single need on ‘one-size-fits-all’ premise. Sure there is personalization, but the underlying fabric of value remains the same for most of the users. This very nature of these products, make them immensely scalable as well if executed the right way.

Enterprise products, on the other hand, attempt to fix processes. These processes have multiple stages with different parties, data needs and pain points. Here are two well known examples of B2B products:

JIRA, the project management software, tracks a task or feature request from a requirement definition to deployment stage. It involves product managers, designers, developers and quality assurance engineers as different parties. It attempts to digitize and streamline the process of software project management helping the entire team stay on same page with regards to the progress on the project.
Salesforce, the lead capture and sales management (CRM) software, tracks a lead from Call-to-Closure stage. It involves data mining, inside sales, sales and account based marketing professionals as major parties. It attempts help sales teams to record, track and manage their sales activities.

Any mid-market or large-market enterprise has dozens of processes. These processes are for both internal and external activities. It is these processes that help organizations increase their operational efficiency by understanding industry best practices for different activities and figuring out what works best for them. Operational efficiency along with a right business strategy provide a formidable competitive advantage to the organizations. Absence of either of these diminishes businesses’ effectiveness and chances of winning.

Now these processes take time to be implemented, adopted and refined. Process setting and auditing is a tedious task in large scale organizations because it challenges the status quo. You need buy-in (and willingness) from different parties involved in these activities. Management will push for process implementation only if chaos is outdoing growth and velocity. The perceived value of change should exceed the cost of status quo. So, overtime processes are set up, adopted, measured for effectiveness and improved. Many new job opportunities are also created around these processes during this time.

Also, though the baseline process for same activity in different organizations may not be too different, the exact implementation details usually vary. For instance, the implementation of JIRA for different project teams would have different statuses and transitions that any issue would move through during its lifecycle. Even the level of detailing required for each issue in terms of form fields will vary from organization to organization.

Software products attempt to take these processes to next level of operational effectiveness by automating some of these, eliminating the outdates ones, and streamlining the remaining. And, in doing so, it is natural to expect some disruption. To be able to successfully deliver value, the product team should be first able to decompose and understand the different components of the process and infer why these components have evolved the way they have. This helps in the following:

Understanding the cost function the process intends to optimize. e.g. TAT reduction, cost reduction, data loss minimization, fraud prevention etc.
Understanding different personas, their goals, scenarios, task flows, motivations and pain points.
Understanding the regulatory framework, if any, affecting the process. e.g. GST regime of the country would affect most of the accounting and payment related processes.
Understanding partnership dependencies. Many processes have data import or export dependencies on other related processes. Decomposing the process, helps understand integration requirements with other products addressing these allied processes, and/or, evaluate the need for new partnerships with parties that can enhance the value proposition altogether. e.g. While a company dealing in digital food cards might have to integrate with an HRMS product for seamless employee on-boarding, a potential partnership with an existing offline network like Sodexo may provide significant competitive advantage over others.

All these constraints and dependencies of the process doesn’t leave you with full creative freedom to figure out an easiest possible solution to the problem. How you plan to solve the problem also become a lot more important. While you would want to productize and simplify many aspects of this problem, you may not always have the bargaining power to do so. This happens especially when you are an early stage company operating in a market dominated by service organizations and bureaucratic enterprise buyers who are least open to embrace changes. Not to forget, the risk of trusting change with an unproven player is also very high and ripple effects of failure for a critical process may be significant.

With market maturity and more successful implementations, you can position yourself as a thought leader and may gain a commanding say in the enterprise implementations to take the market towards standardization. But till then, you need to take all stakeholders along and optimize the cost function of the process you are fixing.

What does this lead us to?

This leads us to a many good things as well as not-so-good things. Let us look at them. What is good or not-so-good is a matter of perception :)

A sales funnel. If the specific market you are operating in is not matured and evolved enough, product driven growth becomes slow and sales teams step in to bring all stakeholders on the same table to close the deals.
Misaligned incentives. Sales teams work on closures and incentives. Closures and incentives are short team. Product teams work on delivering the vision. Vision is long term. Closures bring revenues and delivering on vision keeps us competitive. If sales is not educated on the vision of the product, and incentivized for long run success, overselling instances and customization requests start surfacing often.
Channel sales and strategic alliances. Complementary products placed adjacent in the value chain team up and start offering bundled packages. This increases the reach of the product but deceases team’s connect with the end users.
A configurable product. Configurable ≠ Customizable. To cater to the process differences of different organizations, the product is built in a way that the base architecture remains the same but certain aspects of the product are kept configurable which can be toggled/set up as required for the enterprise. This does not however mean that the company would undertake new custom development for any prospect. Leaving money on the table rather than serving a customization request is preferred.
Complexity. Capturing the entire offline process and digitizing it essentially leads to a complex product with multiple personas, scenarios, task flows, and corner cases. Inter-module dependencies and scope of errors increase. Data points to be captured for web and mobile analytics increase. New features require more development and testing time. Dependency on early engineers and principle architects increase. If you see yourself running into a lot of post deployment issues and your product team is seen running to the developers to confirm how the code actually works, you need a good senior product guy to sort things out.
Integration projects. Most enterprise processes are usually somehow or the other intertwined with other processes. A company looking to overhaul one of the processes, is most likely to ignore products which can not talk to (integrate with) other products that are already in place. This makes it extremely important for any enterprise product’s viability, that it is aware of other prominent products in the enterprise value chain and supports integration with them, if required.
Product adoption becomes easier. Thanks to the top down implementation, management usually takes the onus of getting employees started with the product, with or without the help of product relationship managers.
User research becomes easier. Again thanks to top down implementation, you have easy access to your users. Makes it easier to interact with them time and again and test a lot of things.
User experience may go for a toss. Incentivized sales teams and buy side stakeholders under perceived reward for change management often urge for early shipments. This may lead to focus on functionality and affect both code quality and user experience.
High risk and reward. Since the risk involved in changing the status quo and implementing a new product is high, the buyers usually seek opinion from quoted and independent references. While a spree of successful implementations can be highly rewarding in terms of securing deals and building entry barrier for new players, a few failed ones may prove very costly too.
Predictable revenues. Enterprise software products usually works on SaaS model. One time implementation charge and recurring monthly revenue are two major revenue streams. The cost of switching to a new product is usually high and a business would not do so unless the existing product is really failing to deliver. So, if you can deliver value to your existing customer, a certain MRR is predictably secured.
A marketplace. If you manage to successfully scale the product to an extent that you own a significant market share, chances are you have a steady revenue stream and your primary focus is increasing stability of your existing product and working on the next BIG release in terms of market opportunity. You will still get thousands of requests for new features and functionalities but they may not be relevant to your entire customer base. More importantly, when operating at such a scale, the opportunity cost of working on these requests significantly outdo the marginal revenue benefits to your company. Building a two-sided marketplace is most optimal solution for this. Think of it as a platform or an app-store where independent developers can build and submit Add-ons that work with your product to enhance/extend it functionality or to help it integrate with other products. Two most prominent examples are ‘Salesforce AppExchange’ and ‘Atlassian Marketplace’. Not only does this open up a new revenue stream for you but this also comes with a built-in virality component.

Building for enterprise customers may seem like a tedious, never ending build trap but done with patience, focus and a well defined and communicated scope across the company, it can be highly rewarding as well.

Reach out to me if you would like to discuss further on this topic or if you have any exciting product opportunities for me. I am at bits.ankit@gmail.com | https://www.linkedin.com/in/a4ankit/ .