Enterprise products are hard to build and even harder to scale and manage. The goal of this post to call out pitfalls that companies encounter in this space and what product managers can do to avoid some of them. A lot of the problems outlined here are applicable to small companies trying to scale or break into a market and may not be applicable to large companies with established products and lines of business (Read as IBM, Oracle, SAP etc.). Market research is hard In the enterprise world, it’s a lot harder to do research on what would really help a business. Usually, founders of companies tend to be from the industry, this creates an advantage and a big problem — Your only expert at the outset is the big boss. Opinions can’t be treated as requirements and deep user empathy cannot be gained from one person’s ideas. This causes a huge problem — You will always be stuck between doing more research and going with what you have. User Interviews & workshops are great tools to gain insight but in the enterprise, world users are not easily accessible. Say you were building a lightweight ERP — You would have to find out who the target user is and then have very detailed conversations with them about what they do today and how. Why would somebody spend that time with you? What is in it for them? Say you did that, the next step is to design a prototype and show it to them to get feedback and see if it works. If the user has no motivation — No money on the table, no way in which he can do this and not miss his/her deadlines at work, then you have reached a dead end. Often, the real test happens when your sales team is doing a demo in a vendor evaluation process. This is not a conducive environment to get feedback. If your product is a bad fit — News spreads in the market and it will be harder for your sales to get a foot in any door. Secondly, Sales & Pre-sales are trained to find fits whereas Product teams are trained to find gaps that they need to build for. So feedback from Sales on product features needs to taken with a pinch of salt. Often you reach a point where you can’t go any further. This is when you hire somebody from the industry to be an in-house expert. The Industry Expert Conundrum When a tech company hires a business expert to guide them with functionality, two things happen: They hire an expert who is great with the business process and has years of experience behind him but no idea how to work with analysts and developers. They hire an expert who has a lot of experience working in the space on another software. With variation 1, everybody assumes that this person will solve all their problems and will give direction in terms of requirements. In this process, they forget to set expectations with the product team on how they should work with this expert and with the expert on what he/she should expect on the job. As time goes by, the expert begins giving solutions instead of framing out underlying problems. When the expert says — “ Just add a checkbox here to do this”, take a step back and find out what is the requirement. The problem needs to be understood and not the fix. Once the problem statement is well defined — the solution options become a lot clearer. An in-house expert must be treated like a customer representative in a requirements gathering workshop. In variation 2, the tendency is for the expert to tell you how it’s done in the other software rather than what the problem is. Again, I can’t emphasise this enough — Understanding the underlying business needs is important. If the product team has to be effective, they need to question everything till they get down to the why. To summarise : Hiring an expert will lead to frustration unless expectations & outcomes are clearly outlined. Partner and build with a customer When a company starts out, it is common for them to find somebody who is willing to become a development partner to build out the initial version of the software. The upside for the customer is better negotiation points.For the product, it is the collaboration with users. This approach has its own dangers. Inherently, everybody runs their differently. The challenge for the product team is to identify commonality and isolate specific processes. Due to intertwined relations with the customer, this becomes supremely hard. business Why should the customer share his knowledge and compromise a process he is comfortable with for the sake of your software’s future? We could argue contracts, educating the user about the terms of the partnership etc. At the end of the day, it all comes down to their comfort and how the software makes each individual’s life easy. When any of this is compromised, conflict begins. Often, software implementations are driven by the management’s motivation of reporting and better oversight rather than the end user’s efficiency. This makes the end user hostile. My preference is to partner with 2–3 customers in a geography ( if you are lucky enough to manage that), this way you will have a much better view of what is generic in the industry and what is actually a custom process. The customisation trap One of the biggest issues with small product companies in the enterprise space is the availability of customization revenue. I know I m calling it an issue whereas everyone calls revenue a boon. Often, the problem is that the customization costs are much higher than the license fees for the deal. This is a real conundrum for a company to be in. The product can be customized in-house so they will have to run a project to do that thereby creating a service unit within the company ( in a lot of cases the core product teams end up with this ). Some customizations may actually require large core product architecture changes and therefore will end up becoming product features thereby hinging entire product release cycle on an implementation timeline. Over a period of time if the product company doesn’t take this seriously enough to build and expose a customization framework(front end hooks & APIs), implementing customization becomes the focal point of every release. This coupled with the lack of ability to do market study means that the product will be completely driven by specific customer requests. At some point, the company will become so culturally embroiled in this that they will find themselves always building for one big customer and culturally unfit to build market features. Think about this for a second, the overruns are huge. Release on release companies will see themselves branching code bases for customers. The support costs will be high, it will be very hard to push newer releases to existing customers due to incompatible versions.It will be hard to build production feedback enhancements back into the main product. I know it sounds bad but trust me — I’ve spoken to companies who branch every customer out and have over 200 code bases to support! The same bug gets fixed across multiple sites because consolidation across code bases is a massive exercise. Lack of focus on User interfaces and experiences In the enterprise world, deals are driven by sales guys who connect with the higher . Often, the daily problems of an end user seem petty when compared to the larger goal of integrated reporting and moving away from a system which lacks control (like spreadsheets). All of this makes for a woeful situation where product teams often realise a hard truth — Functionality comes first, form can be neglected. If the application can do 10 things, no matter how hard those are to achieve, somebody will see the value and buy it. The end user, however, will struggle and often the product becomes clunky and usability goes out of the window. Have you ever used Oracle’s ERP? No user can intuitively navigate and click on the right buttons in one go. You need training to something as simple as submitting an expense. Enterprise products have built a culture of acceptance toward un-emotive and unfriendly systems. management If you don’t incorporate good UI standards and have a UX designer embedded within the product team, there will be a day when you know your customer will hate the product and as a product manager you will have to swallow your pride and de-scope UX improvements because there are other important things to build. This is acceptance of failure after which things can only go south. Business Driven product vs. Product driven Business At any point in time, its should always be the product that is ahead of the business. Sales should be selling what is built and the product team should be telling them that. If sales team is driving the features, that basically means you have signed up for a deal where you need to find out what to build. Without a customization framework that can isolate this effort, you will be staring at a situation where you can never align the sales cycle and your product release cycle, it is a chicken and egg situation. Everything from Strategy to Accounting must align to a product-driven business, that is the only way to make a great product company. Lack of predictable revenues (which are real problems) drive companies slowly towards accepting the short-term rewards. This only means one thing: As a product company, you have failed to study your product-market fit which has led to miscalculated projections in revenues thereby making important stakeholders like your investors nervous. In conclusion, I really think that product management for enterprise products is extremely challenging. It can be very rewarding as a learning experience provided you take the trouble of isolating things that are happening because of culture and because of you not doing your job right. Please leave comments, would love to hear your thoughts.
