Let’s imagine that you always dreamed about having your own tomato tree in your apartment. The journey starts with a small seedling in a tiny flower pot. Beginnings are usually cheerful. You can provide for that “new project” basically everything on your own. You put it in a place with sufficient sunlight access and you water it scrupulously. And what is more important, you can thoroughly combine it with your current job. There is no option that such a little plant would force you to become a full-time gardener!
Eventually, you were able to make this project fruitful. Like literally! Little seedlings evolved into full-grown tomato bushes with appetizing, red fruits. This is a moment of great excitement, joy and pride. An MVP (in this case, it’s fair to say it was MVT - Minimal Viable Tomato) was presented to the first users - your family. It turned out that such a product can vastly enrich family meals. A unique flavor mixed with a substantial dose of potassium made customers delighted. Your wife told her friends about that. And who would have expected that? Sally, her friend from high school, who currently is a VC fund manager, really liked that product. She believes in socially conscious business and thinks that growing healthy tomatoes on a bigger scale can change dynamics in nutrition. Sally proposed you $10M funding and hoped it could allow you to scale production and conquer a broader market.
It’s definitely a big thing for you. You feel excited but also a little scared. You are passionate about growing tomatoes and you know 1328 varieties of tomatoes. But now, you are involved in building two greenhouses. And you have just found out that there are 35 types of glass which can be used for covering construction. Subcontractor demands direct requirements in that matter, you need to decide, but until today glass was just glass for you. And Sally disturbingly often mentions acronyms like ROI and P&L in your conversations.
But let’s leave behind those gardening metaphors. And speaking about software products, what the most common problems in the post MVP phase, that give CEOs sleepless nights, are.
One of the problems, which would arise quickly, is a phenomenon called technical debt. It’s one of the most misunderstood phrases in the IT industry. Some people think about it as an incarnation of the darkest evil and try to avoid it as much as possible. And often the scariest sentence for the product CEO can be heard somewhere around: - “We need to rewrite it!”.
Source: https://vincentdnl.com
What we should do instead is to treat technical debt as a tool, the same way as we treat a bank loan or a credit card as a financial instrument. They can be used for achieving our goals, or they can be harmful in irresponsible hands.
When we treat debt as a tool, we can approach it in a pragmatic and healthy way. Thus, we shouldn’t speak about paying it off but rather managing technical debt, which basically means adjusting company leverage. If the interests eat all our efforts, we should think about deleveraging. If the dev team constantly struggles with delivering new features, then a surgical refactor in a contention point will probably allow them to breathe.
The second issue that can arise post MVP is a team topology. From our experience, we can say that the optimal size of a typical product team is 8-10 people. The team states a peer-to-peer network, adding more and more “nodes” to it, makes things hard. That’s why it is crucial to pay attention to the signs of that communication overload. There is a natural equilibrium point beyond which the increasing team size exposes us heavily to the law of diminishing returns. If we hope to allow teams to achieve their full potential, we should aim at maximizing their autonomy. The team should be capable of delivering a stream of value through the whole stack.
Additionally at some point, it’s beneficial to distinguish different team types, in order to offload more and more specialized duties.
As in the example with a part-time gardener and the seedling, having one person who covers many areas of growing a plant is a natural and optimal solution in the beginning. This is also true for digital products. Initially, the two important people for each startup, CEO and CTO (technical co-founder) truly are the jack-of-all-trades. But it’s not the same after landing a successful MVP. In the former, you usually need to have a generalist. The farther you are in the product journey, the more specialization you need. This can be particularly true, when a rapidly developing product outgrows the capacity of people who support it. When speaking of the initial CEO + CTO setup, it can really constitute a glass ceiling. And it’s always a question about the ability and willingness to evolve along with the growing product. Many products had that luxury of having people with great vision, who were able to adjust to the changing environment. But unfortunately many do not.
It’s worth knowing that this isn’t the only one way to bootstrap products. Sometimes choosing a software product development company can be a smarter move. If this topic sounds interesting, you definitely should check this article.
As you can see, scaling an MVP is associated with a full variety of challenges needed to be solved on the way. In this article, we have tried to cover these most often occurring ones and not trivial at the same time. We hope that it can shed some light on this matter. In the next articles, we want to focus on these specific problems and decompose them thoroughly.
But... maybe you are just facing challenges after an MVP phase? Do you find them alike? Or you face a different beast? Let us know!