Building Product – Transitioning from a Service mindset

Many “realworld” ideas that initiate the launch of a startup have their roots in the world of “services”. Somewhere, someone who was trying to solve a problem for a customer realizes that there is a major need for a viable repeatable solution, their idea/approach to the process/solution method looks structured enough that it can be “productized” and hey presto, may be worth launching a startup. Most of us have seen this in verticals ranging from media, ad tech, analytics and more. However, this path of transitioning from relevant idea, to performing “service centric” projects, to building a worthwhile product is fraught with numerous pitfalls (confronted by startups in general) but there is something unique to startups where the core founding team has their basic upbringing and learn their ropes in a service context  such as consulting, running operations (sales, marketing, customer management), project/program management in any vertical. Over the past decade, I have worked in and with teams/peers from a range of such backgrounds and have learnt a lot from them. However, I would like to briefly highlight some of the key potential blind spots that may confront such service-mindset driven startup teams in defining a product, building the product, selling the product and supporting the product.

Defining what is the “product”:  Outlining the core features of  a product is a major exercise. What is that minimal set of features with some “tech” barrier that provides a baseline for future development and is still a viable MVP for customer engagement ? Given the service mindset, feature creep and the inability to draw a line between product features versus “services” is a major pitfall. The resolution is not to hire a product manager to manage the product, but the core team has to first internalize what makes up the “product” and its value proposition. If the boundary is not clear to the core team, a product manager cannot enforce such a boundary without proper conceptual constraints in the founding team. Though one may profess to following lean startup ideas and such, practising the same is quite difficult (reading a book versus actually doing it). The key to a successful product is to getting rid of unwarranted features as early as possible, (even before development!). Though you want to please the customer, You should decide on pleasing them with just one core set of themes/features/value, that others in the competition do not yet have and make it extremely easy to use that feature. This is your beachhead to build upon. Establish the “magic sauce” and its boundaries as early as possible with the current toolkit you have.

Building the product:  Most realworld problems require solutions that are complex and products have a number of features driven by different objectives – easy to engineer and maintain, fits in with the current wave of tech buzz, core beliefs of the founding team as what to have/not have, what does the competition have/not have and finally, what does the customer want, really need and wishes to have. Considering that coding/tech is the easy part once things are defined, the most important aspect is picking the right features/functionality at each layer of the “architecture” to support the initial core functionality. Making choices with many future needs in mind, overwhelms engineering as the dependencies mushroom making delivery of a decent working MVP difficult. It is an important issue to test if you want customer feedback before or after the first core version of the product is built. Leaning more towards the customer too early adds to the complexity and may mis-inform the team as to what to focus on. All customer input is not equal. Furthermore, though folks may have built tech earlier in their careers, the tech toolkit is constantly changing, old rules may not apply. Additionally, you need to be clear if the development efforts are for throwaway prototypes used to define the product or core aspects of the future product. Tech. teams need to be focused on core aspects rather than short term needs, depending on resource availability.

Selling/Marketing the product: Once the first revision of the product is beyond the demoable stage, selling the current revision for customer engagement, POCs  and initial adoption has to be done with discipline. A clear picture of what the product can do with current features and what are the benefits has to  defined. This has to be communicated to customers and the aim should be to find customers who want to work with what is on offer. Finding such customers is the difficult part. During this phase, it is easy to get misled by non product-centric customer requests (that do not improve the core product) and under revenue pressure take on service centric activities which are peripheral to the product development activity. The whole focus (even while attracting initial customers) is to refine product-market fit,  focus on identifying high value features/functionality in the product and the nature of customers who want such features. In a noisy market with many competitors, lookalikes, one is easily distracted with adding me-too features and providing non-core service functionality. Generating revenue or building customer base only becomes a focus after a stable beach head is established. In a service business, the quick cash flow is attractive, but in a product business it takes immense discipline to build the right product to get sustainable revenue else you falter. Jumping the gun without doing so usually does not help and burns resources.

Serving the customers – Solutions around the product: Once a core product is defined, built and deployed, peripheral derivations and solutions activity can consume resources in efforts to retain customers. It is important to be disciplined in choices of what features become core to the product and what are delivered in partnership with other third parties. May be the growth curve is muted because of such a choice but it may be worthwhile to do so in the near term, in order to develop the product to the next level of core functionality ahead of other incumbent products. One should also be comfortable to let customers go if they do not fit in with the core mission of the startup.  Avoiding dilution in focus is key. Every customer/partner is not equally important.

Overall, transitioning from a service mindset is very much possible and many good folks have done it. I see many of my peers trying to do so and run into the same aforementioned issues as they navigate the world of startups. Having a sense of what is important from a product perspective, taking the time to do so before resources are frittered away, having the discipline to stick to it is essential for success. Many interim strategies are possible such as: a) having a service arm in the organization to maintain incoming revenue b) outsourcing/offshoring the service org, c) partnering for services etc, but each of this has costly overheads (though you generate revenue to minimize funding risk).  Such overheads which drain a startup’s resources include: a) distraction between product and service focus, b) the cultures of a service organization and product organization differ remarkably in people, processes, expectations, incentives and c) as a startup your mission looks diffuse, your paths of growth look shallow/bushy and unnecessary complex.  Building a successful product company is an all-or-nothing proposition and accepting that early enough in a startups lifecycle can be highly beneficial.  Many of the aforementioned thoughts have emerged from my discussions with folks in big data analytics startups, media/ad -tech startups (producing content or running mini-agencies), product development offshore shops in mobile/web as they attempt to transition and redefine themselves. Hopefully, these musings help some entrepreneurs refine their thinking/strategy as pursue their vision.