— with Kate Semenova, IT Project Manager at Rademade
Tristan: Let’s hear about software startups from the perspective of Lead Project Manager Kate Semenova, who is from Kyiv-based software development company – Rademade.
What have you found to be the most effective way to deliver MVPs for Startup entrepreneurs?
Kate: It can be tricky because there is no one size fits all solution. However, there are certain suggested steps to follow whether it be a fin-tech startup or a new fashion mobile app.
ShortCode has bad parameters
1. Start with the business analysis phase
Before we define what the best approach to product development, we often undertake a fairly detailed Business Analysis phase together with the Product Owner.
We need to establish a baseline level of understanding of the following:
- Exactly why the Product Owner and Client want to create this product
- Who will be the End-User(s) of the Product
- Which User Problem(s) will be solved
- What could constitute a suitable solution to the User Problem(s)
Once we have established a high-level of understanding of ‘Why’ we are creating the solution, then we deepen our investigation by creating a User Persona for our end users.
From this, we will begin to understand who these people are in terms of:
- Their general behaviours;
- Where they will come from;
- What their problems are;
- What concerns they have; and
- Their existing approach to solving these problem(s).
Caution: Please note that it greatly depends on your product and go-to-market strategy what are important sections to include as part of your User Persona. And sometimes the user isn’t as important as other factors, i.e. specific use case for example.
We can then move on to creating empathy maps to understand:
- Their feelings;
- What they think & see etc.
The result is the alignment of understanding and expectations between both Product Owner and development team. With a clear understanding of why we are building this product, who will use it, and how we make their lives easier, we can move forward.
2. Creation of high-level requirements for the software application
Based on this information we can start to create a set of high-level requirements for the app, together with the Product Owner. These requirements help us to create a prototype in order to better understand the Final product featured set of the MVP.
3. Problem-solution fit & product need validation
Once we have a prototype in hand we can do a decent level of product validation with the end customers – to double check that there is a need for the product in the chosen market segment. It also helps Product Owners think about monetisation for them to get a return on their investment in software development.
There is a lot of literature how to test and validate products. Without going into detail, here are some of the most informative books on this top:
Once a basic level of product need has been validated, then we can create a roadmap for MVP development, with our goals, metrics and KPIs. We need to make sure our MVP is business-oriented as well.
Roadmaps can have many formats, one of the most popular is using a Gantt chart. Do make sure however that your roadmap captures the overall product strategy, releases, features, goals, dates, responsibilities and costs at a bare minimum. You can access a template by clicking on the image below.
At this stage, it is also possible (and often recommended) to do more customer and market-validation by testing and analysing the Product Marketing strategy, Go-To-Market Strategy and competitive landscape.
4. The need for ‘commercialisation management’ knowledge on the project
But, as a development company, we have only got the time and expertise to assist with the basics to ensure that the Product Owner begins to understand their Commercialisation Management role. It is recommended, therefore, that the Product Owner self-educate as much as possible and/or seek assistance from an experienced Product Manager or Go-To-Market Strategist.
The Product Owner must self-educate as much as possible and seek assistance from an experienced Product Manager or Go-To-Market Strategist.Click to tweet
Tristan: Yeah, so from what it sounds, you’re at least establishing a level of problem-solution fit and reminding Product Owners that they have to speak with their customers and have an ongoing dialogue. It’s a learning curve for many product owners, particularly if they’re first time Product Owners.
(On that topic, here’s another useful blog: Essential Reading, Listening and Viewing for Founders of Product Startups)
Kate: Exactly. As soon as Product Owners recognise this need, we start the next stage. However, we cannot move forward until they receive this prerequisite knowledge which is why we sometimes take on the role of educator and mentor our clients, which can be delivered as dedicated one-on-one sessions and/or preparation of specific materials for them.
5. Supporting and strengthening our Product Owners
Tristan: So, you’re supporting that as part of your operations at Rademade, right?
Kate: Yes, because we’ve met a lot of Product Owners who have never done product development before. It is difficult to ask them to get their product to match the needs of the market and do a lot of research when they do not know about digital go-to-market strategies for their type of the product. They just get frustrated. The phase we do before the development is often the first time that the Product Owner learns about true Product Ownership (often confused with the simplified definition of the Product Owner in SCRUM).
Tristan: Yeah, because even with YouTeam, we see a lot of founders come to us and expect to bridge straight into development. In an actual case, there are a few phases before that. Including the planning phase (1), which you’re describing, then there is the design phase (2) and then a team assembly phase (3) which can take weeks or months depending on your approach. These three initial phases are really the bare minimum which must be done before the development.
6. A brief word about the team assembly phase
Tristan: It is extremely important to find/assemble the right team for your project. Outsourcing is almost always an option, however it is often deceptively difficult for first-time founders or those who have only used traditional in-house recruitment. Fortunately, for those founders, there is an easy way to hire software developers by using a specialised platform like YouTeam.
Team Assembly Process includes:
7. Why we need suitable product documentation?
Kate: The reason why we need all this information is because it is valuable for the product development team:
- Customer Personas are valuable for designing the UX and understanding End User behaviour.
- Understanding the roadmap of future features will help the developers create the correct architecture without needing to re-create it every single sprint. The roadmap provides a high-level project plan so that the development team knows what to expect in the future and how to prioritise their time and effort.
Another reason the design and development team needs to understand the vision and product need is that this will make them feel much more motivated. They will feel empowered to make more creative decisions and solutions to problems rather than just solving some direct tasks requested by the client.
8. What are the details of the product documentation we need to start the MVP development?
Tristan: Thanks Kate for explaining some of the fundamentals about how to arrive at the initial scope for your MVP. Can you please elaborate on exactly what other documentation we need to provide to commence with MVP development?
Kate: First of all, I ask my Product Owners to create a Lean Canvas (1), to express the general idea of the product to the team as well as to explain uses cases, product need(s) and the project goals.
Clicking here takes you to a free service where you can create lean (and various other kinds of business) canvases online.
After that, together with the Product Owners we create User Personas (2) including an image of a real person with a photo, a description of his age, education, needs, worries, life goals, sales/marketing channels to reach this user, and which of his problems are we going to solve. We are trying to visualise him.
Then, we build high-level features, which are Epics (3) based on the User Personas. These are described in the following format:
As a <persona> I want to do <this>, so that I can achieve <my goal>.
In this form, the developers can understand the business goal and keep in mind the personas we are building the product for.
Then together with the Product Owner, we create the Roadmap (4) of these high-level features, to have a goal for release with specific dates and to keep the team focused on the primary goal of the release. If we are building an MVP, we can set a goal by features, plus we can set other metrics for the MVP.
For example, we can set the objective of the MVP to launch a product release which will enable users to register on our platform and to get information about our customers. And the goal for the release could be the number of users we want to get.
Tristan: That’s an important point, sometimes people are creating a P2P marketplace (primarily for mobile) but one of the most important things to do as a Product Owner is to create a website so you can build up one side of the marketplace in anticipation of product launch (not the whole product at once). So you have to be very clear on what you’re wanting to achieve with your first release.
Would I be correct in saying that you start off with quite high-level requirements and gradually, as you progress and the product vision gets clearer you start to clarify things and get more into the details?
Kate: Absolutely. Basically, all this information: lean canvas, user personas and empathy maps help to understand the product itself and gradually transition into details at the level of User Stories (5), all the while remembering the primary user(s).
Tristan: Thank you, Kate, for explaining the preparation stage to us. It will help startup founders to recognise the significance and scope of preparatory phases required before commencing with development and in turn help them to set more realistic milestones and timeframes for developing their products.
Kate is a Lead Project Manager at Rademade. Main specialisations are project and team management as well as project planning. She accompanies projects from idea to implementation and is responsible for planning the work of the teams. Previously she worked at New Strategies Group and Prodigi digital agency.
Rademade is an expert team consisting of hand-picked professionals specialising in Project Management, UI/UX, Front-end, Back-end and Quality Assurance and more. All of their specialists have experience of working with AGILE methodology using SCRUM.
Services: Consulting, UX/UI Design, Development, Support.
Technologies: Ruby, Ruby on Rails, Elixir, AngularJS, Node.js, Backbone.js, Ember.js, MarionetteJS, Karma, CoffeeScript, jQuery, HTML5, CSS3, SASS, Stylus, Rupture, Jade, Bootstrap, Gulp, PhoneGap.
Design: Sketch, Photoshop, Illustrator, Craft, Balsamiq, Axure, InVision, Zeplin.io.
Specialties: SaaS, Consulting, Startup, Web Development, Design, Support, Consulting service, Mobile apps, Trading platforms.