Pretty much every time I work with a team that are about to start building a new product, they choose to start by implementing the login flow. It’s the start of the user journey and how people will access the product, so it makes sense to start there, right? In that respect, yes it does. But let’s take a few moments to consider that decision a little more carefully.
All new product endeavours start with a number of assumptions. Assumptions about what people want from the product; assumptions about how people will interact with and understand it; assumptions about how to build it. In the same vein, my colleague Gianpiero Puleo, and Kent Beck in a recent tweet, both state that early product development is more akin to answering a series of questions than it is ticking a list of features.
If choosing to adopt contemporary methods for bringing a product to market, then the aim of the delivery process should be to remove these assumptions and answer these questions systematically, starting with those which have the greatest impact should we get them wrong.
Let’s take Monument Valley as an example. When the team had the idea for the game, which was inspired by the art of M.C. Escher, there were a number of significant unknowns. Will anyone find a game about impossible architecture fun? Will anyone understand how to interact with something so visually difficult to comprehend? Is it even possible to build with a game engine?
The Monument Valley team decided to start by creating a very simple level of the game as this would provide vital feedback about the technical feasibility. Once they had this feedback they then incorporated that back into their plans and moved on to try and figure out the ‘fun’. Imagine if they built the login flow first and then found out it wasn’t even technically possible to build, or that it wasn’t fun; all of the time spent on login would have been wasted.
The longer that a team defers testing their most critical assumptions and answering their most significant unknowns, the longer they carry risk and therefore the potential of wasting energy and precious time. Rarely (and I only say ‘rarely’ to be safe) is login the part of the product which has the most significant assumptions or unknowns.