Our philosophy at AndPlus follows the Agile development methodology. By way of review, Agile breaks down a development project into short (one- or two-week) mini development cycles called sprints. A fundamental principle of Agile is that at the end of each development sprint, the team should have a working (albeit not necessarily complete) version of the software product.
Before you can start building a product, however, you need a design. You wouldn’t build a house without blueprints, and you wouldn’t put on an event (such as a wedding) without a plan. So, too, developers shouldn’t write any code without a design to code against.
As the name implies, the product map sprint is a short process in which we define the software product design.
Unlike more traditional development methodologies, in which the design phase could take weeks, if not months, incorporating a product map sprint into the Agile development process ensures that a comprehensive design is completed in a short time. Moreover, the output is a prototype suitable for review with the customer, who can then provide immediate feedback.
The product map sprint includes the following activities.
It’s a fair question to ask: If we’re in such a hurry to get a working product out the door, why take a week or more for the design? Why not just give the developers a rough idea of what’s needed and let them get started?
Simply put: Too many software projects fail because they don’t meet customer expectations. Often this results from simply taking the high-level problem description provided by the customer and running with it. These descriptions are rarely, if ever, sufficient to flesh out a comprehensive design, let alone start coding.
The product map sprint is worth the time it takes because it ensures every detail of the business problem is understood. We end up asking the customer a whole lot of questions along the way; this is especially important if we’re not really familiar with their industry.
But most important is the prototype evaluation at the end. This is the customer’s opportunity to let us know if we understood their needs accurately and have designed a solution that will meet those needs. If we missed the mark, it’s better (read: cheaper) to find out at the prototype stage than at final product delivery.
Doing software design this way gives us peace of mind that we’re on the right track. We know, going into the development sprints, that the design will work and meets the customer’s needs because they’ve already reviewed it and given it the thumbs-up.
The end result is a better product and a happier customer. And that, ultimately, is the most important goal of all.