Digital product development – from idea to conception
Picture the scene, it’s 4 o’clock in the morning and you’ve suddenly been awoken by the switching on of the proverbial light-bulb. That is, you have just had a great idea for a digital solution to a real world problem and you now want to transform this idea into a great digital product that you are confident will change (or at least improve) the world. The only question is, how do you go about turning this great idea into a reality?
We shed light on some key areas which should help you take that idea closer to a real product.
A prototype, in the context of developing a software application, is much like a prototype in any other industry, it’s purpose is used to explore some aspect of a system, either in it’s entirety or partially.
The design phase for an application should include a prototyping stage. It is at this point that interested parties can experiment with the idea and form a proof of concept. It can also serve to give you valuable feedback that shapes the final designs before you begin development. This can save time and money in development, and create products that offer better user experiences, rather than ones that move from concept to production with no evaluative stages in between.
Prototyping can help you to realise the viability of a product without committing to production. When a prototype proves the concept works, there is sometimes the temptation to use it in the final system. Some may reason that “the prototype works well, so why not save on time and costs by continuing its development into a production model?” However, it is important to remember that the very nature of prototyping, namely that they are usually built quickly for demonstration or explorative proposes, means that many aspects of a prototype will not not be suitable for production use; think in terms of security and scalability. So prototypes should typically be discarded after the evaluation stage and should not be in the final product.
Minimum Viable Product
Remember the old Facebook motto of “Move Fast and break things”?, well that’s essentially the idea behind having a Minimum Viable Product (MVP). It is similar in principle to a prototype, namely that you want to have something working quickly, however the fundamental difference is that you want a viable product, which you can offer to customers and present to others as a production unit. It should be a barebones version of the full and final product. Think of it as version 1.0, a product with a minimal baseline set of core features. We’ll come back to versions and ongoing development later.
When it comes to launching a new product, the wrong way to launch is to spend too much time planning, building and testing lots of features without any customers. There are many reason why this is not a good idea, one of the biggest being that in the fast moving tech sector, whatever user needs were identified during the analysis and planning stages may have shifted significantly during the product's development lifecycle, so much so that many of the features in the final released product are no longer relevant. It could even be that whilst you were off busy planning, your competitor has already moved into the market and begun servicing your customers! It is one of the main reasons why an Agile development methodology is preferred to the Traditional Lifecycle Cycle (TLC) or Waterfall approach to development. So think fast, think core features, and get that minimal product out into the world.
As a side-note, Facebook’s new slightly less catchy motto is “Move Fast with Stable Infra[structure]”. I know right.
Managing a project requires a special set of skills, whether on an individual basis, in a small start-up or a large corporate team. Taking any idea into the real world should be viewed as a project, which requires careful management. Some of the key areas you will need to become familiar with, if you’re not already, include task management, scheduling, leadership, the ability to prioritize and control cost, risk management, and good verbal and written communication both internally and externally.
You should decide whether the product will be developed incrementally, that is start fast with a few core features and improving as time goes on, much like having version 1, then releasing version 2 with more features and so (this is the Agile approach), or at the end of a given timeframe doing one big release (TLC). You should decide on an appropriate methodology by which your team delivers and if required continues to develop the product. A methodology is an overall approach to developing a product, think of it as a guiding set of principles, which govern a projects development using procedures, techniques, tools, and documentation. We wrote about it in detail in a previous article available here.
Even the most ardent, self-reliant go getter will often require or benefit from outside support. Whether this is obtained through research or by outsourcing depends on a number of factors; including the available human resources, budgets, in-house know how etc. However, wherever possible, it is usually quicker and easier to use an agency with the expertise of product development such as Big Blue Door, who can do a lot of the heavy lifting like project planning, scoping, development and delivery for you. Feel free to get in touch here.