Sidekick product
Throughout my career, I participated in the development of a few supplements for so-called “parent” products. They were standalone services with their own, not big, but still considerable business value. Recently I realized that even though those supplement products were developed in different organizations and in different business areas they did have common traits. Moreover, they shared the same problems.
It was something laying on the surface. Sometimes you shoot yourself in the foot twice before starting to see obvious things. What is the nature of those Sidekick products and do they inherit the problems of “bigger brothers”? Let us sort it out in this essay.
Sidekick’s characteristics
A Sidekick product may appear near a “big” product when there is an opportunity to address business needs that do not exactly lay on the main product direction. But still, such Sidekick can potentially bring additional value to the business.
Here is a list of the characteristics for identifying a Sidekick:
- It can’t exist without a “older” brother and it is very attached to it.
- It is considered to be an easy try to gain more with fewer efforts
- Quick development using already existing components and known practices
- Everyone is very excited about it (so far).
At the same time, those points are Sidekick’s strengths and the pitfalls hidden under the surface. What I learned from my experience (in a hard way), the wrong decisions from the start, even for the supplement, are very difficult to handle on the way. Similar to the “big” products, the sidekicks should not be treated carelessly.
Sidekick pitfalls
1. Flexible vision & great expectations
After starting building something “quick and dirty” you might very soon realize that it is not “quick” anymore. And this becoming dirtier and dirtier. It is a common situation for any product, but for the Sidekicks that is more fatal compared to others. Different sides push it in different directions which have been not considered from the beginning.
Sometimes that is for good: history knows a lot of examples when a Sidekick resulted in a successful standalone product or even a new business. But history usually avoids mentioning a graveyard of the products with a such “flexible” vision.
Stakeholders are excited about the new opportunities. Each has its own view on what should be added to make a proper solution. That causes an overload and losing the initial vision of the product. In the end, that leads to failed expectations from different parties.
You’d better know what you are going to build. And also, be pretty confident about what you are not.
2. Prolongating MVP development
This is an obvious consequence of Point 1. Unnecessary prolongation of an MVP stage is a common disease in any industry. But with a Sidekick, it is relatively easy to fall into an endless extending/redoing cycle. The unclear vision and desire to address the needs of every stakeholder makes the exit very complicated.
On the other hand, if your MVP appears to be not very “V” (viable/valuable) because of the rush and not listening to the right guys, then welcome to the Sidekicks’ graveyard.
3. Lack of architecture guidance
A Sidekick is expected to have a very quick time-to-market period. And such phrases as “Let’s deal with (put your option) later” on the MVP stage, along with quick and unjustified tech decisions, could lead to the exhausting on-the-fly architecture changes. Lack of the proper architecture guidance from the start may cause time-consuming refactorings when a Sidekick becomes mature and need to address more complex functionality.
Especially that hurts when your go live with it. Your team quickly realizes itself buried in the problems with scaling, performance, and integration. And the Security team is knocking on your door with a bunch of found vulnerabilities to be resolved ASAP. I bet you haven’t got that planned initially.
4. Team unfocus
If you launch a Sidekick be sure your team will develop it along with the main product. I don’t have any data on this, so let it be my assumption: you are unlikely to get a new team or new hires for a supplement. That might happen in later stages when a Sidekick proves its stake. But for the beginning, you are likely to handle that with what you have.
Considering points 1-3, you can imagine how that affects the main product. All that might seem to be a temporary shift in the priority to push the Sidekick as much as possible and return to the mainline later. In the worst case, you found yourself chasing two hares with low chances to catch any.
5. Selecting a new technology stack
The team might be eager to try new frameworks, programming languages, and libraries with a Sidekick. Nothing bad with that, but you should consider the risks which appear there. Lack of experience may introduce architectural issues and a bigger tech debt to be resolved if the Sidekick transition to a mature “production-ready” service. The cost might be too high.
Also, the learning curve for new technology can be very long. That causes potential issues with implementing complex features so the team will be not able to resolve that without outside help. That is OK when someone in your organization has experience with that stack and can dedicate some time to help you. But if not then you are in trouble. Hiring a new developer for that purpose or engaging a contractor/freelancer brings risks to a new level. Waiting until the team will be experienced enough to handle the complex feature might not be an option as well.
6. Selecting the same stack as the “Parent”
The team is familiar with the technology so we do expect that even complex issues will be resolved in the known domain. However, there are new risks here:
- Bringing bad practices from the Parent to the Sidekick.
- Unnecessary tying the Parent with the Sidekick.
Using the “Parent” stack seems to be an easier way. And, actually, it does. However, there might be cases when some solutions could be done better (quicker and with more quality) if developers were not looking back on the Parent and bringing some practices from it. Those practices might be good there, but it is not always the case for the Sidekick.
Also, tying the Sidekick with the Parent on the program and infrastructure levels can result in a very painful divorce. Such kind of migration will freeze the implementation of new features and cost many efforts.
The best recipe is not to be afraid to bring some innovation and explore new technological capabilities for a new product. But ensure that someone in the team or in the organization can guide you in that journey.
Outro
The main idea here is “please do not underestimate the complexity of a Sidekick product”. Treat it as seriously as a “big” product by investing time into defining vision and solid architecture from the start. This is not a recipe for success, but it still increases Sidekick’s chances to go to Production and bring expected value to customers.
Next time I will share with you a real case of such a Sidekick. Stay tuned!
Take care,
Ilya