About

George Krasadakis

17+ US patents on Artificial Intelligence, Analytics and IoT • 20 years of digital product development – from concept to launch • 80+ innovative, data-driven projects • 10 multinational corporations • 4 technology startups • Founder of ‘Datamine decision support systems’.

Defining and engineering AI-powered products • Leading technology innovation programmes • Extensive experience in Software Engineering, Analytics, and Data Science projects. Views and opinions are my own.

Medium:https://medium.com/@gkrasadakis

Linkedin:https://www.linkedin.com/in/gkrasadakis/

Q.1 Why should startups begin with building a Minimum Viable Product?

Startups should naturally think in terms of MVPs.

The MVP approach, if applied properly, allows startups to ship their product earlier and satisfy their early customers, by solving their core problem. This way, startups can avoid the development and operational costs of those not-yet-needed features. Startups can make better use of their limited resources, and launch features according to top priorities and needs of their target customers.

Startups need to move fast and follow truly flexible adaptive product development patterns. The experimental nature and the limited resources of the typical early-stage startup require laser-focus and smart prioritization; which is the basis for defining a Minimum Viable Product: the MVP is all about identifying the smallest subset of the product, which can be built first to deliver value to your users, as early as possible.

The Minimum Viable Product is about what to build when – in what order; it is about learning from customers and adapting. It is perfectly aligned with a good startup strategy – it is a great beginning for a startup, a framework to balance excitement and pragmatism.

Q.2 How do you prioritize features for a Minimum Viable Product (MVP)?

Well, prioritization can become quite tricky and complicated. To assign good priorities you need to combine strategic thinking, product vision, empathy, market insights and also sufficient technology understanding and domain expertise.

My strategy when prioritizing features is based on deeply understanding the problem, the impacted users, the competition and the state of the art. To prioritize wisely, I ensure that - as a product development team - we envision the ‘ideal’ state and that we are able to clearly articulate ‘how to get there’. I emphasize on the need to understand what is already available in the market, along with the opportunities and the constraints of current technologies.

I do believe that having a bold vision and the ability to ‘think big’ is critical for prioritization. If you are aware of the full potential, the ‘big picture’ of your product, prioritization gets easier and more meaningful. In fact, the more features you have to prioritize, the better the final priorities will be: when you have your ‘full product’ described at the feature level, the relative importance of each particular feature becomes more clear; while the risk of ‘opportunity cost’ – from features that you didn’t consider to build – drops. This is why I encourage the product team to define not only the obvious features but also ‘crazy ideas’ and creative ways to solve the problem for our users.

To get the first definition of the MVP, I work closely with the product development team to ensure that each of the features in the backlog get assessed in terms of value to the user, feasibility and cost. This assessment process leverages all the knowledge, the signals and the insights we have — everything we know for the users and their pain-points. The objective is to assign a single value to each product feature, reflecting its importance in solving the problem for our customers; as early and inexpensively as possible.

During this process (which could have many iterations - reviews with stakeholders and refinements), we keep ranking the backlog by ‘importance’. When the prioritization is stable enough, we draw the line separating the MVP from the rest of the backlog. This is the first definition of the MVP.

Depending on the case and the complexity of the product, I might consider additional research techniques to validate assumptions and get more detailed insights from users. Or visualization tools to provide clarity on the product backlog, the priorities and the roadmap.

Q.3 What is the best advice you can give to budding Startup CEO on developing a successful MVP?

Think as a user; act as an entrepreneur.

‘Thinking as a user’ implies empathy and deep understanding of the market and customer needs. ‘Acting as an entrepreneur’ implies a strategy, wise use of the available resources and responsiveness to signals from the market – along with the right approach to balancing risk. This is the right mindset to have when defining your Minimum Viable Product and your overall product strategy.

As a CEO, you need to ensure that there is a solid, inspiring product vision there; that your product management team and your stakeholders deeply understand the vision and the roadmap. State your assumptions and validate them as soon as you get the right insights and data. Build a data-driven culture but also emphasize critical thinking when interpreting your data. Make sure that your team appreciates the culture of experimentation and values how data-driven decisions can improve your product development efforts.

Use Agile engineering practices, stay connected to your customers, get ready to make pivots when there are strong signals from the market. Step back, look at the product ‘from a distance’; ask for honest feedback from people outside your domain.

Define a solid success measurement framework for your MVP. Make a small investment to build a ‘product performance dashboard’ which automatically quantifies product engagement metrics and user feedback into KPIs vs targets. The measure, interpret, react.  

Or, you can skip all the above and hire a great CPO 🙂

Q.4 How can you save some extra cash when developing an MVP?

Assuming a good definition of the MVP and also proper execution, you will avoid unnecessary costs by building only what is needed to achieve your short-term goal: to engage with your customers, cover their core needs and learn. With the MVP you are building a smaller first instance of your product; successful execution means smaller engineering/ development and operational costs.

In some cases, the MVP could even generate early revenue streams – which, depending on the business model and the stage of the startup, could prove to be important for further product development and user base growth.

Q.5 Is building MVP still useful in 2019 and coming years?

Well, I believe that MVP reflects a particular approach or philosophy for building products – which should and will be there as ‘common sense’ for product development. Moreover, when building digital products in this rapidly changing technology landscape, you must constantly apply critical thinking about the definition and prioritization of product features – or you can easily get distracted and take risky paths.

I strongly believe that – regardless of the actual terminology used – this approach makes perfect sense and will be there as the basis for modern product development.