Projectize Your Product?

Wait, isn't it supposed to be the other way around?

Indeed, if your company is working in the B2B software domain, chances are high that your product leverages intellectual property (software code, custom processes, patents) the company has gained through many previous successful projects. In other words, you have productized your project experience and IP, possibly looking to diversify from a constant struggle of a project-based business. 

From a project to the product, and back?

So, you have built an MVP and gained some paying clientele. While you are trying to learn as much and as quick as possible to find the perfect product-market fit, your finance department breaks an uncomfortable truth – your product balance sheet is still negative (losing money) and the allocated budget for product development is almost gone. 

Somehow in parallel, you have managed to secure a new large client, worth as much as all the others, which would tip the product balance sheet to clear positive. As with most large clients, they have many important and non-negotiable requirements. After a careful analysis, you come to understand that, while your product may be a great fit for 70% of these requirements, the other 30% do not fit your product vision and indeed require a significant change of the existing functionality. Struck between the option of losing a large client to continue delivering your product vision, and taking an opportunity to buy some additional time for your team with a one-off custom project based on your product, you must decide quickly. Yet, no option seems particularly attractive. You cannot afford to turn down a large client, but defocusing your development team from the product has also significant drawbacks, such as losing competitive advantage and demotivating the team.

Alternative view

Let me then unveil several additional paths that the modern techno-business environment of the software industry provides, in addition to the aforementioned extremes.

1. Functional encapsulation. Yes, I have conveniently borrowed this term from object-oriented programming languages' dictionary. But the basic idea is maintained - breaking your business logic into „functional capsules“ which can be independently reused in the context of a specific project. Redesigning your product around the microservices architecture pattern is one possible and quite popular approach to it. This is also probably the most expensive one, in terms of development resource utilization, if your current software product architecture is a monolith. On the other hand, microservices architecture would also likely provide other benefits to your product, in addition to enabling reusability for ad-hoc projects. Having a paying client might be the perfect opportunity to take on the redesign effort if you can already foresee these other benefits for the product. There are many excellent articles about microservices architecture, but for a novice on microservices, I recommend these two: What are microservices as well as How microservices architectures affect product manager’s job.
2. Licensing your IP. While the previous approach potentially brings many long-term architectural benefits to your product, in the short term it also means a significant slowdown in new business value and features for existing clients, while your team tackles the steep learning curve of the new architectural pattern. An alternative option could be licensing your existing IP to a third-party company that could do client-specific customizations. A partnership agreement could also include some of your consulting knowledge in the initial phases of the project for the client.
3. Evolving your product into a platform. The third approach sits between the previous two approaches in terms of complexity and time investment, however, it is possibly the most lucrative in terms of the future of your product. Transition to a platform-based business essentially means enabling others to add value and build solutions on top of your product. Google Maps is one great example of a platform product: while Maps are a product on its own, their APIs allows any programmer to include parts of Google Maps functionality in the programmer's own app, or simply, embed a full Google Maps display in it. Let's think about your product again. If there is one client who found value in your product but needs heavy customizations or additions to it, there may be others too. For some products, this transition may start as simple as opening a set of APIs (Application Programming Interfaces) for other software makers to leverage. The leap from a product to a platform is generally far more complex than that and beyond the scope of this post. However, I may at least ofter some further reading on the topic. I promise it will be well invested time: How to turn a product into a platform, Platform strategy: Building an engine for enterprise evolution.

I hope my view on "projectizing your products", or choosing an alternative path to the classical project vs. product approach, provides you with some food for thought, as well as additional options will you ever be on a similar crossroad. I know I was, and I wish I knew then all that I know now!

I am sure there are many more worthy experiences and approaches to situations like these. Please share yours in the comments below!

Previous post (Croatian only): Produkt menadžer - (ne)skrivena tajna uspješnih softverskih proizvoda

Next post: Soft Skills - The Swiss Army Knife of a PM (coming soon!)