Frankenstein Products in Project-Based Companies
For a company to exist, it needs to satisfy the cravings of a certain range of customers producing and maintaining services. And for the company to succeed these services need to be the solution (at least partially) to a problem the customer has.
In most cases, the methodology and procedure to develop and maintain these services (especially software-related ones) corresponds to one of these two categories:
- Project Management.
- Product Management.
The different methodologies in both categories can potentially achieve the same results with the same constraints but the required mindset in each of the categories is completely different. In Software Engineering, project management is associated with waterfall and product management with Agile. Considering the creativity and uncertainty in software development, it looks obvious that the methodologies in the second category are the ones that fit better with it.
There is a special group of companies that develop products in an innovative environment using project management. These are R&D companies, companies that need to wrap their ideas into projects to be able to apply for funding.
Research Project-Based Companies
Identify the product portfolio is a very simple activity in many companies. For example, for companies who develop mobile apps, software tools,… the product is the app/tool. R&D companies operate at a high pace and often they will need to change drastically their goals to be able to adapt and anticipate the market making the product portfolio a living entity with high fluctuations. Because of this and also because R&D departments are normally part of big organizations (the ones who have the economical capacity to finance pure research activities), the business model operation is frequently project-oriented (ideas that are born and die in short periods of time). But what happens with the tools and software products to support the delivery of the results?
These are some common points that these companies have:
- Total revenue streams are the sum of the benefits from each of the projects upon partial or total completion.
- The results of these projects are data accessible to the customer via a software platform.
- The development of the software platform to deliver the results is considered a company’s internal activity.
- The knowledge and project domain is distant from software development.
A project outcome as a product
The main outcome for the projects in these companies is data. These datasets are shared with the customers/shareholders through reports and software tools that allow them to access and do basic data manipulation. Each of the projects could be considered a product, but what about the software tools (internally developed) to share the results of the project? It is the software tool a product by itself, or is it not?
In order to answer this question you need to identify the customer and the producer:
- Customer: a customer could be a consumer, someone who uses your tool without paying for it, or a buyer, someone who does not use your tool but pay for it. And of course, a customer can be both.
- Producer: this is who receives a benefit for developing the tools through revenue streams, cost decrease, or social benefit.
A software tool internally developed by a company to bring results to clients could potentially be treated as a product in which the customer is the people who access the outcome data of the projects and the producer is the team who develops the tool. Until here everything looks correct, but what happens in many cases is the next: the revenue streams for the development of the tool are smaller than the ones from the research projects or even no existing at all. This leads to placing more emphasis (in terms of personnel and investments) on the generation of the data for the projects than the tool itself. The software tool is still a product, but it can easily become a Frankestein.
Frankenstein Products
When talking about Environment, a Frankenstein Product is any product that is made out of two or more components or materials, which while apart could have been disposed of or recycled, but are now a burden on the environment, as they can no longer be separated. A similar definition could apply to Software Products. A Frankenstein Software Product is one that is made of multiple components that have differently purposed and are based on completely different technologies, therefore reducing the reusability.
Coming back to the Research Project-Based Companies. They deliver the results of their projects using a software tool that customers can use to visualize and manipulate the data. Because each of the projects could potentially deliver data from multiple knowledge domains (and formats), the software tool needs to adapt to the singularities of each of the projects.
Under this development flow, the tool became an amalgam of features, each of them following a complete and isolated goal, sometimes a one-time usage. Each feature became a silo making it difficult to define a vision for the tool itself.
Is the software tool a product? Without a vision, it is difficult to have a product, because the value of the product is diluted in the chaos and complexity of the multiple projects sharing the same workspace. But still, the software tool can be treated as a product and chances are that the tool is developed by a team following Agile practices, probably Scrum. This also means that there is a Product Owner, managing a product without a vision.
Product Management applied to Frankenstein Products
If you find yourself as a Product Owner in this situation it is complicated to scape the proxy-trap. You have multiple stakeholders (at least one per project manager in the company) with a high impact on your product with a low (sometimes no existent) connection between them. Because the value of each project can only be measure in the context of the specific project, how could you make decisions on what feature/project your team will work on?
Still, there are some solutions that you can apply in your situation (probably not the best ones but at least will be effective):
- Revenue/cost of each project
Use revenue/cost of each project to determine the value of the integration of that project into the tool. From a financial perspective, this is the safest solution but it could lead to making decisions that strategically will not be beneficial for the product and the company. Considering you have access to the total budget costs of each project, this is also the simplest solution: give more priority to the project which brings more revenue independently of the impact.
- Delegate priorities to the executive layer.
The idea behind this solution is to look for a person in the company who is in a position in which she can oversee all the projects and make that person your main and unique stakeholders. This solution will work from a strategic (and probably financial point of view) but it also adds a high degree of subjectivity to the design of your product. You have one stakeholder and the success of the product will therefore depend on one single person.
- Prioritize by committee.
Create committees in which the maximum responsible for each project is present. This solution will potentially be ideal from a financial, strategic, and objective point of view. But the time needed to coordinate the decision, process length, and the energy needed could be devastating from market competition and potentially create delays that increase the time to market ratio of your product.
All of these solutions have two aspects in common:
- Focus on one specific variable: finance, impact, costs…
- You became a proxy between the decision-maker (finance, strategic, or operations respectively) and the product
This will leave you with almost no space to take your decisions or even create a vision and both things are essential for the definitive success of a product. I am not saying these products can not exist, in fact, they exist and many of them have a good market viability status but will rarely become a reference in the market in which they operate. This is not bad per se, but you need to adjust your personal expectations.
