Build and Scale Enterprise Products: Insights From a Microsoft Product Lead
Build and Scale Enterprise Products: Insights From a Microsoft Product Lead
In this article, we discuss one developer's insights gained from working with Kshitij Saxena, a product lead at Microsoft.
Join the DZone community and get the full member experience.Join For Free
A common problem that enterprise SaaS products face is not being able to scale the product quickly once they are past the minimum viable product phase. This challenge is especially large when there are incumbent solutions in the market already that your’s is competing with.
Kshitij Saxena, a product lead at Microsoft faced a similar challenge as he built the Edge mobile browser for enterprise from the ground up into a tremendously successful product. He leads a portfolio of enterprise SaaS products at Microsoft and is a versatile product leader with a passion for seeking out problems and building experiences in the enterprise space. I’m sharing some valuable insights — what I learn from him on how we address these challenges across the different phases of the product life cycle.
Developing the Product
1. Identify Your User(s) and Engage With Them
This should not come as a surprise to anyone who is building a product, regardless of whether it is for enterprise or consumer software. However, this is a little complex in enterprise products which usually have at least two types of users for the same product and often they have conflicting pain points.
Typically, they would be the end-user of the product and the IT admin that deploys and manages the product across the organization. Understanding the unmet needs and pain points of both types of users and getting insights on what they are looking to accomplish by using your product is key.
Going down to the detailed workflow becomes critical in accurately identifying unmet needs. Identifying and engaging with these users not only results in the right functionality being built, but also drives clarity in how to prioritize types of users all up to help deal with conflicting requirements and needs between the different types of users.
2. End-User Walkthrough for Insights
The importance of design walkthroughs is a cheap way to validate your solution for unmet needs without actually having spent development time to code the feature/product. This is particularly important for enterprise products because, generally, users are already performing the task at hand in a different but cumbersome way.
If directly asked what could be improved, users would come up with suggestions that would only be slight improvements to their existing solution. A disruptive solution should ideally improve the workflow by leaps and bounds in comparison to the existing alternative, and a walkthrough allows you to showcase it and get early feedback, which could often be counter-intuitive.
Moreover, the lead time between building the feature and actually being able to test it with a real user is much longer than consumer products because of the overhead in setting up and refining the environment for testing since enterprise products usually rely on many other products/extension/integration. This can differ from customer (enterprise) to customer.
3. Prioritize Features Solving for Pain Points Rather Than Habit-Forming Features
Enterprise products should always be about what the user is looking to get done, as opposed to spending more time on the product. The amount of time spent on the product is definitely some measure of success for the product. However, it should be a byproduct of the user being able to get a lot of things done rather than just spending time in the tool.
Remember, task completion should always remain the true north when prioritizing features. Saxena highlights that products solving for the unmet needs of the enterprise (customer) are comparatively much easier to sell that one that needs you to explain the problem to the customer before trying to sell the solution.
4. Scope Out a Credible MVP
The critical functionality that the MVP would deliver is extremely important because you generally get one shot at convincing the customer (enterprise) to consider your product. Therefore, while product development should be iterative, the scope of MVP should address the most important problem/scenario that the customer would be willing to pay for.
If the MVP is not scoped out well and ends up falling short of delivering a solution for the scenario that the customer sees as most valuable, that exhausted lead would take a long time to restart because usually enterprises have spending cycles for technology infrastructure and missing that cycle would mean having to wait for the next.
Selling and Growing
Once you have a product that has achieved a product-market fit, it's time to focus on sales and growth. At this point in time investing in sales channels becomes a higher priority than for an enterprise product because the most effective customer acquisition channel for enterprise products is sales driven.
1. Earn Your Customers’ Trust
Large enterprises deeply care about the confidentiality and control of their data which means that despite your product being perfect for their scenarios; they might not come on board due to lack of trust. Therefore, it becomes really important to invest in building trust through various means. Saxena believes that enterprise customers often go with a solution that they trust more with their data than the best product for their needs. Trust can become a huge competitive advantage.
2. Design to Minimize Overhead Costs and Barriers to Onboarding
One of the most important ignored aspects of enterprise products is simplifying the onboarding process. The harder it is to get onboard/deploy a product, the less likely an organization would use your solution. Therefore, it becomes critical for the deployment and setup of an enterprise software product to be quick, easy and scalable in order for it to succeed and grow fast.
The complex and tedious setup and deployments are not only slow and issue prone but also costly for the customer and no organization would want deployment cost to go up since that defeats the purpose of the SaaS business model.
3. Do Not Customize for a Single Customer: Always Design Product for Customization at Scale
While engaging with customers, a product team can easily get drawn into the trap of building features that cater to the unique requirements of those customers in the spirit of being customer-centric. This costs dearly, since it hampers scalability with the overhead that comes with custom features.
Therefore, it is important to assess whether features that are being planned are valuable to a wide set of customers. Another approach that works well is to build customizability within the product in case the nature of the product requires varied requirements, such as Salesforce.com for example. “Sometimes it is important to say no to a customer in the interest of scalability and growth of the products,” says Saxena.
4. Manage Big Changes Carefully
Significant changes in the product both visually and functionally always need to be well informed through A/B testing and other channels. However, for enterprise products, it becomes even more critical because even a small change that disrupts the customer’s business briefly could be a trigger for churn. The most important thing besides customer research is to set expectations in advance before making the change and give them time to prepare for the change.
Published at DZone with permission of Ved Prakash . See the original article here.
Opinions expressed by DZone contributors are their own.