The keys to successfully plan product development

Now you’re all set.
You have an idea.

You have confronted it in the market and achieved a real problem-solution fit. 

You have mapped your ecosystem and drafted a business plan to achieve a product-market fit. 

You feel ready and you want to execute this idea. You want to go from earlier prototypes or PoC (“Proof of Concept”) to a real MVP (“Most Valuable Product” which definition we like is the minimum product for which a User is ready to pay for). Later incrementing and improving it, little by little with the lean startup methodology. 

So what’s next? In the Agile Manifesto, there is a statement describing the methodology as a tool “responding to change over following a plan”... so there should be a plan and adequate preparation. 

What to do? how to organize? what to prepare? how to plan? 

We try in the below article to provide some guidelines, tools and best practice to maximise the development team’s understanding and therefore efficiency. 

 

Product vision

The first thing is to clarify product vision.

The product vision aims to set a goal: what do we want to build ? for whom? why? what is the place where we want to be in 3-4-5 years when the product will be delivered? what impact should it have? 

The 'why' is very important as it facilitates team engagement and alignment. 

Like the north star guiding the crew sailing towards a destination. It does not matter if the ship will sail in different directions, it can actually change (pivot) but the end goal being clear, allows to keep the final objective in mind (at sight). 

 

Personas

It’s crucial to understand and map for whom and why we’re developing the product. 

This is done in writing Personas coming from user research.

Personas help in building empathy. Users' goals and needs become a common point of focus for the team. They generate a consensus within the project team. And they allow defending decisions.

 

Journeys and mapping

At this point, users, their needs and their “jobs-to-be-done” (what they will do, using the product) shall all be known. The next step is to connect it all. Journeys and mapping are a great tool to achieve it, and it can be done in various ways. 

 

User story mapping

For a particular user (Persona), user story mapping is a great tool to frame the journey, identify key activities and organise the execution with user stories. It is also a great tool for prioritisation and therefore, plan releases. It can be done at any stage of development though, doing it early is very advantageous. 

 

User Flows

User flows can be very useful, for example for describing processes and rules. They are very easy to create (Powerpoint, Draw.io for example… there are many software for that). They can also be used to describe a user experience, explaining the team how to get there. 

When UI is prepared, we like to build user flows with screens (using overflow.io as an example). This allows great product visualisation and understanding while reducing a lot risks of logic mistakes or forgotten stories. 

 

Customer journey

Common in the world of marketing, customer journeys allow mapping the total experience in which the digital product takes place. 

Besides the journey itself, as a “job-to-be-done”, customer journeys allow mapping user empathy (like feelings, thoughts) and opportunities along its way. They are de facto very useful in B2C applications. 

 

Storyboards

Storyboards are a much more concrete method. In many ways, software storyboards can be compared with movie storyboards or comics.  

For examples, see storyboard templates.

The quality of storyboards can vary tremendously from rough sketches to very nice drawings or designs. The main goal is not about graphic user interface but about the journey, the experience (how the User will interfere with the product), the context, so its ideas and logic become clear to the team. 

 

Epics

At this point, personas (users), their “job-to-be-done”, the flow and framework shall be defined and known. This is the time to get prepared for later details, starting with Epics which is the first step in translating the digital product or application into design and user stories. 

Epics can be seen as very large user stories, sometimes as “features”. The main reason to write them is that they provide the “bigger” picture. See them as the chapters in a book. Example of Epics could be “User logs in” “User search for Item X” “User adds X to its basket” “User checks out”... 

They allow better understanding of the product vision and its alignment during the sprints with proper prioritisation.
Doing the above solely on user stories would be much more complex. 

 

Roadmap

A product roadmap aims to present the steps to go through to achieve the product vision. It generally maps the above epics upon a timeline showing priorities and connections. It helps to communicate where the product stands today, the direction in which it’s moving and how you expect to get there.

The roadmap includes business goals and objectives, product areas, order of priorities and scope.
There are many ways and tools to make such prioritisation, taking into account risks and opportunities.

 

User stories

After user journeys, epics and their planning in a roadmap, it’s time to plan the details and that is the moment where User Stories may be prepared. They are the structure on which the execution is related to.

Beyond the “who / what / why”, the most important thing is to keep them short, simple and representing a very small chunk of a feature. Crucial as well, is to define clear “acceptance criteria” associated with the definition of done. 

User Stories shall be written at least to cover the first one or two sprints.

But to facilitate the preparation of the release plan, they may be prepared to cover the full MVP preparation, even if written in a preliminary way (beyond the first sprints).

 

Team building

Well, you’re all set. You have the whole plan, from the bigger strategic picture (vision) until its very core details (user stories). 

It’s time, if not already done, to organise and build your development team. A typical team includes back and front end developers, a product manager (who generally covers the product owner role), a designer and a quality assurance expert. They can be part or full time, there can also be several persons for a role to increase velocity.

Generally, the team is built upon the product constraints (such as technology requirements and orientations) and needed experience (B2C vs. B2B, web application vs. process digitization, product from scratch vs. incrementation, …). 

At Startup Development House, we ensure the proposed team best fits the purpose of the project to maximise its chances of success. 

 

Release plan

When the roadmap is the big picture, the strategy, the release plan is its execution in more details, its tactics. It provides a clear timeframe, objectives and KPIs.

The release plan is built based on: 

• user stories and their time evaluation,

• your team and its expected execution velocity.

It illustrates connections, blockers (a story/epic which needs to be executed before another one), due dates…
As for the user stories, the release plan is done at least for the first features. The further away (from these first features) and the more likely this tool will change.  and that is why it is a “living tool”: since the team will work in agile, the priorities may change, the feature definition may evolve, new items or tasks may appear, all possibly impacting the release plan. 

Conclusion

The benefits of a preparation phase before starting the first sprint is crucial. In software, aiming at fast or cheap is often resulting in moving slow and expensive. Like for building a house, before you start pulling concrete or gathering its wooden framework, you need to plan design and build strong foundations.

In Startup Development House, we pay the highest attention in succeeding in developing great products. And that is why we pay so much attention to these foundations. When we plan any digital product or application, we assemble a team of experienced experts in their fields - developers, product managers, designers, quality assurance - and pay great attention to the quality content of the above-mentioned steps.

It doesn’t matter if a project is small or big or if it is very complex or not… the right amount of preparation will always result in a more focused and efficient development with an increase of quality of the actual digital product/application.

Any thoughts you'd like to share with us? Drop us a line: hello@start-up.house