Congratulations, you’ve just come up with an awesome startup idea that’s going to change the world! And after all that initial positive feedback you’re now ready to press play. As a former co-founder, I can tell you how seriously exciting this moment is. The moment when a startup creator, after months of discovery, planning and improving an idea, finally sees his or her product on the market.
But before going any further, let’s check whether your team has the proper go-to-market plan to ensure this market debut goes as smoothly as possible. A well planned go-to-market strategy will help to avoid the mistakes many startup founders commit when entering their first ventures.
So let’s define ‘go-to-market'.
There’s little doubt that in an ever-changing startup environment, timing matters. Especially during the post-MVP period and scale-up stage, where gaining the client’s favour and loyalty is so crucial for cultivating growth in product awareness.
Nevertheless, for better or for worse, it is common for a startup to use different software houses/developers for the varying segments in service development. Actually, it strikes me how often we’re asked to form a product team and estimate on what are very loose terms. “Only add a few functionalities” or “just fix a couple things” we often hear. Whilst for a developer familiar with the source code this may be a walk in the park, it is certainly not so for a new team. One unfamiliar with the project must spend hours analyzing each task in order to determine the best approach. And the result? Estimation vs realization disparity, frustration, decreasing confidence and leveraged risk. Here’s where both money and momentum are lost. The wellbeing of all co-operation strongly depends on the mutual understanding of those involved: how something works (or is supposed to work) and how you, the brains behind it, understand its nuances and challenges.
This is what I call the walking phase - so important before the real jogging starts!
Despite each scrum team being unique and every project different, we still seem to face the same old problems when it comes to the development cycle. Among the most common is the planning session. When it’s long. When it’s unproductive. Reasons may differ, but here I’ll try to cover a few main ones in addressing the question: What should a product owner do to be best prepared for productive sprint planning?