Get asset ready: The do’s and don’ts of the App Store and Google Play
6 minute read
What approach do I choose for my product?
It’s common to hear some of these terms when you’re working with a team making a web, mobile or connected application of some kind. Understanding the differences between these concepts can help stakeholders and non-technical team members contribute fully in the process, which is always a good thing!
The aim of this blog is to explain these terms and give some examples and practical insight.
1. Spike
What is it?
A development spike is a time-boxed (AKA time limited!) research activity aimed at investigating a specific technical aspect of a project. It is often used to explore potential solutions, gather information, or validate/de-risk a technical approach before committing to it.
An example:
Suppose you are developing a mobile app and are thinking about using a specific library/tool for real-time in-app chat functionality. A development spike in this case could involve spending several days experimenting with this library/tool to understand its performance, integration challenges, and potential issues.
Why it’s useful:
- Risk Reduction: Helps identify potential risks early in the project.
- Informed Decisions: Provides valuable insights that inform subsequent stages of development.
- Focus: Provides a quick evaluation without a significant time investment.
Guidance for non-software readers:
Think of a development spike as a quick and focused “test drive” to understand something discrete/specific to see if a particular route is worth pursuing further.
2. Prototype
What is it?
A prototype is an early, very simplified version of a product or app. It is developed to test key features and functionality before progressing to building the complete system.
An example:
Suppose you are a startup developing a brand-new social media app. Before building the full app, you create a prototype that includes basic user interface designs and a number of core features such as user registration and posting updates. This prototype helps all stakeholders understand the purpose and UX of the app and may be used for gathering feedback in the form of external user testing.
Why it’s useful:
- Early Feedback: Allows users and stakeholders to provide feedback early in the development process.
- Concept Validation: Helps validate the core ideas and design choices.
- Communication: Serves as a tangible model to communicate the vision of the product.
Guidance for non-software readers:
A software prototype is like an architect’s model of a building. It provides a tangible representation of the final product to gather feedback and make improvements. It’s not the real thing, but it allows you to learn lots about what’s right and what’s wrong.
3. Minimum Viable Product (MVP)
What is it?
An MVP is a version of a product with just enough features to satisfy early customers and provide meaningful feedback to drive future development typically in the form of a backlog (like a to-do list) of prioritised upcoming features. It strikes a balance between delivering core functionalities and launching quickly.
An example:
Suppose you are developing a new project management tool. You might release an MVP for sale that includes essential features such as task creation, task assignment, and basic reporting. More advanced features like integration with other tools or complex analytics can be added later based on user feedback.
Why it’s useful:
- Market Validation: Tests the market demand with minimum investment.
- User Feedback: Gathers valuable feedback to help direct future development.
- Early Revenue: Enables early monetisation and iterative improvement.
Guidance for non-software readers:
An MVP is like a basic version of a product that can be used and evaluated, allowing you to learn what works and (just as important) what doesn’t before investing more time and resources.
4. Full System
What is it?
When we talk about a full system, we mean a complete and fully functional software product that includes all (or most) planned features and integrations. It is the final stage of development after thorough testing and refinement. Even after its initial release, a full system will have iterative updates that add new features and fix bugs/issues.
An example:
After several iterations of prototypes and an MVP, you finally release a comprehensive e-commerce platform. This platform includes all essential features like user management, product catalogue, shopping cart, payment processing, order tracking, customer support, and advanced analytics.
Why it’s useful:
- Complete Offering: Provides a complete solution to users with all intended “version 1” features.
- Scalability: Built to handle larger user bases and the corresponding higher performance demands.
- Reliability: Comprehensive testing to ensure stability and robustness.
- Continuous Improvement: Reactive to user feedback, delivering regular updates to improve and enhance the system.
Guidance for non-software readers:
A full system when released is like a car at the dealer, ready to go, with all the features and refinements included, but still receiving regular services and upgrades to maintain its performance and add new capabilities.
Key takeaways
It’s important to understand that every stage serves a specific purpose in the development process – from exploring ideas and gathering feedback to delivering a complete, market-ready product.
Choosing the right approach for a specific need not only massively reduces risk but also ensures that the final product is as well-aligned with user needs and market demands as possible.
Not sure what strategy is right for you? Contact us to discuss your project. We’ll be happy to walk you through the various discovery steps, including technical spikes, prototype creation, and MVP development through to full systems.
