Starting a new development project can be both exciting and overwhelming.
Do you start with a Minimal Viable Product, a prototype or a proof-of-concept? When do you use a spike solution, and what is a walking skeleton? In this post, I'll explain these terms and guide you on when to use each approach.
And so it begins
Before you begin writing the first line of code, several critical decisions need to be made. Some of the important ones include:
Defining the scope of the project: It's important to know what the project is supposed to achieve and to set limits on what's included and what's not. This helps ensure the project stays on track and that you can get everything done within your time and budget.
Choosing the right technology stack: The technology stack you choose will depend on the specific requirements of your project, as well as the skills and expertise of your team.
Setting project goals and objectives: Clearly defined goals and objectives help guide the project's direction and ensure that you are working towards a specific outcome.
Assembling a team: Depending on the size and complexity of the project, you may need to build a team of developers, designers, and other specialists. Be sure to choose team members with the right skills and expertise and good communication and collaboration skills.
Establishing a project plan: A project plan outlines the tasks and milestones to be completed to successfully deliver the project. It helps keep the team organized and on track and delivers a roadmap for getting everything done.
Setting a budget: Determine the project's budget and use it wisely. This will help you make intelligent choices about what's possible and outside the project's scope.
But there's another, often overlooked, decision to make. It's tempting to launch straight into building a fully loaded, feature-rich, state-of-the-art application. But this is not always feasible for greenfield projects.
In a greenfield project, the requirements are usually not known in advance in full detail. A greenfield project is a new project that starts from scratch and doesn't have any existing infrastructure or systems in place. Therefore, the requirements for the project need to be defined and refined as the project progresses.
So how do you start building without a complete understanding of the requirements? Well, that depends on where you are in the development process.
Minimal Viable Product (MVP)
When starting a new project, the go-to approach used by most teams is to build a Minimal Viable Product. An MVP is a minimal version of a product with just enough features to allow users to experience the product's core value proposition. It is typically used to validate product assumptions and gather user feedback.
Creating a minimum viable product (MVP) to kickstart your project can have several benefits, including:
Validating assumptions: An MVP allows you to test your hypotheses about the product and gather user feedback, which can help you identify and address any issues or problems early on.
Gathering user feedback: An MVP allows you to gather feedback from users about the product's core value proposition, which can help you refine and improve the product.
Minimizing risk: By building an MVP first, you can reduce the risk of investing time and resources into a product that may not be viable.
Focusing on the most important features: An MVP allows you to focus on the product's most important features rather than getting bogged down in unnecessary details.
Building momentum: An MVP can help you build momentum and generate buzz around the product, which can help attract investors or customers.
Overall, creating an MVP can be a helpful way to validate assumptions, gather feedback, and minimize risk as you develop a new product. But building an MVP might not be the right approach for every project.
Reasons not to build an MVP
The complexity of the product:
Creating an MVP may be challenging if the product you are developing is very complex or requires a lot of resources to build. For example, it would not be easy to streamline a highly complex product with many moving parts. In these cases, building a prototype or a proof-of-concept (POC) may be more appropriate to test specific ideas or concepts.
The stage of the development process:
MVPs are typically used later in the development process when a minimal feature set is ready to be released to a small group of early adopters. If you are in the early stages of development and are still working on defining the concept and design of your product, it may be more appropriate to build a prototype or POC.
The size of the target market:
If the target market for your product is small or niche, it may not make sense to invest the time and resources required to build an MVP. An MVP is designed to be released to a small group of early adopters to test the market demand and gather feedback.
If the target market for your product is small or niche, it may be better to focus on refining the product concept and design before moving on to the MVP stage. This allows you to ensure that the product meets your target audience's specific needs and preferences before committing to a full-scale development project.
One way to refine your product concept and design is to use a prototype.
Prototype
A prototype is a preliminary version of a product or system used to test and demonstrate its capabilities and gather feedback. The primary goal of a prototype is to allow designers and developers to experiment with different ideas and approaches and to identify any problems or issues that need to be addressed before the final product is developed.
A proof of concept (POC) can be considered a special type of prototype used to demonstrate that a particular concept or technology is viable. It typically includes a small, focused implementation designed to show that the idea is feasible and worth pursuing.
Both prototypes and proof of concepts are used in the development process to test and refine ideas, gather feedback, and identify potential issues or problems. However, while prototypes are generally focused on testing and refining the design and functionality of a product or system, proof-of-concepts are specifically focused on demonstrating the feasibility of a concept or solution. They, therefore, serve different purposes and are used at various stages of development.
How do prototypes and POCs relate to an MVP?
An MVP is focused on delivering the product's core value proposition to users. In contrast, a POC is focused on demonstrating the feasibility of a particular concept or technology – usually to internal staff. As such, a POC may be more focused and narrowly defined than an MVP. An MVP is typically released to a small group of early adopters or actual users.
Prototypes are generally used earlier in the development process before work on the final MVP has started. POCs are often used later in the process when a product is further developed, and the focus is on demonstrating the viability of a particular concept or technological implementation.
During product development, rather than building a fully-fledged POC, development teams will often use spike solutions to explore feasibility.
Spike solution
A spike solution is a quick, throwaway implementation to explore a particular problem or issue. It is typically used to gather information or test a specific approach rather than being intended for production use.
The primary goal of a spike solution is to gather information, understand the feasibility and complexity of a particular idea, and identify any potential issues or challenges that need to be addressed. The purpose is to gather information and provide a better understanding of the problem so that a more permanent solution can be developed.
While spike solutions and POCs are used to explore and test new ideas, they serve different purposes and are used at various stages of development. A spike solution tends to be smaller and more straightforward and is typically used to answer a specific question.
In contrast, a POC is used to demonstrate that a concept is technically feasible and viable. Both can be useful in the development process, but they have different purposes and goals. Ultimately, they are a valuable part of the iterative process of developing an MVP (or even a fully-fledged product).
Walking skeleton
How do you start building an MVP? An excellent choice is to create a walking skeleton and then iterate features on top of it.
A walking skeleton is a small, minimal implementation of an application that demonstrates the core functionality and architecture of the application. It typically includes just enough code to allow the application to start up and perform a few basic tasks, such as displaying a login screen or fetching data from a server.
A walking skeleton can be a helpful way to get started on a new project and ensure that you are building the right thing. Creating a walking skeleton can be good practice for several reasons:
It allows you to quickly validate your assumptions about the core functionality and architecture of the application.
It helps you focus on the most critical features rather than getting bogged down in details.
It provides a reference point for future development, showing how the application has evolved.
It can be used to demonstrate the project's progress to stakeholders and get feedback early on.
Overall, creating a walking skeleton can be a great way to get started on a new project and ensure that you are building the right thing.
Summing it up
In conclusion, the approach taken when starting a new development project will depend on various factors, including the project's scope, the technology stack, the project goals and objectives, the size and complexity of the project, and the budget.
Some common techniques used when building a new tech product include building a Minimum Viable Product (MVP), using prototypes, developing proofs-of-concept or spike solutions, and starting with a walking skeleton.
Commonly, an MVP is bootstrapped using a walking skeleton, and prototypes are produced by various team members to support product development. Spike solutions are used by developers to solve small-scale technical concerns alongside the development of the product.