Know when to stop prototyping and get (almost) real.
Building a successful product is hard work: many directions are considered, multiple iterations occur, and tons of effort is invested by both design and engineering. But even after that, many products end up solving the wrong problem — even if the solution itself is well-built.
To prevent this, organisations have historically chosen to test different solutions and directions without building an entire product through prototyping, one of the most popular preferences by designers.
Knowing when the limitations of prototyping start doing more harm than good, can be the differentiator between taking a month versus a year to launch.
Prototyping drawbacks we forget about:
While a prototype validates the core concepts of the product, it does so in a mock environment with assumed constraints. These assumed constraints might not always paint the right picture, and can increase your time to go to market with the product:
- Validating value proposition: Unless a user invests the real cost directly in the product, we cannot be sure of the value it would generate to the real users when tested in a mock environment.
- Figuring out idiosyncrasies: Every app or product has its idiosyncrasies that can only be figured once we start building it for users in a real environment. Are people going to allow location access permission? Will people invest their money in this product.
- Solving the right problems: More often than not, our assumptions in a mock environment can close the doors to various possibilities in which the product could end up being used. We can uncover new patterns only when the users interact with the product in their own time. Prototyping in such scenarios might not prove too useful.
Get real (almost) with software
What if we could short circuit a prototype and end product to produce something real, well almost real?
Once an initial study using prototypes / other techniques is done, we get sufficient insight into the usability of the product to identify one core value proposition. This is the cue to get real, meaning the ideal time to identify the product-market fit with a real app. At this point, we build a focused and real piece of working software that has the core solution, with just enough scaffolding in place. We call this a shallow app.
What's a shallow app?
In our experience of building software products we have come a long way to comprehend its power—they are cheaper, safer and easier to change. It's cheap to build and even cheaper to update software products. It's safer to build because unlike physical products it won't adversely affect the well-being of individuals for not being quality assured. It's easier to respond to changes and iterate over and over again until you get it right with the users.
We utilise this advantage of software products. We build a "heavy prototype" with real written code and a real functioning system but cut as many corners as possible to produce a shallow app.
A shallow app works regardless of what form it takes, be that a website or a mobile app. It allows you to change your decisions quickly and quite often, just like in a prototype, but help you base those decisions on the actual behaviour of real users.
At Obvious, we've moved from using only prototypes to shallow apps and built them for multiple clients including Wikipedia, Simple, and Bravo. This has allowed us to move fast and deliver a real app to a closed set of users before making final decisions.
Shallow app guiding principles
To execute shallow apps successfully, there are certain principles we abide by, but we break all other rules:
Set clear expectations and goals
We start by setting a launch date of 3 to 4 weeks. We define our core use cases to focus on—for example, "recording patient blood pressure" or "Start investing by using one type of mutual fund"—in order to focus our efforts. Based on the use cases we set the scope of the product.
We choose “easy over simple” in order to produce something that works and is just enough.
Continuous communication & delivery
Strong communication and tight feedback loops are the backbones of shallow apps. For us, this means releasing the app every day to the internal team—our very own QA—in order to get quick feedback. Engineers and designers bring things to a close by conducting a lot of high-effort collaboration in order to build something so heavily constrained by time.
Choose agility over quality
When building a shallow app, we make calculated compromises on quality which we would never do in a concrete production app. We evolve the design of the product while building it, we rely on testing in production over the automated tests in development. Focus is shifted from a pixel-perfect and quality assured product to the simplest thing that will work.
Collect lots of data
Shallow apps increase reach and help us get insightful information early on, through integrated analytics. The user-related metrics we gain from a larger user base help us answer empirical questions such as:
- Is recording a blood pressure quicker on the app than on a paper register?
- How much time are users taking to reach the investment dashboard?
- How many times do users look at their investments?
Weigh technical feasibility
The tracer bullet approach used by the engineering team gets you a working, demo-worthy skeleton that uncovers potential technical challenges in this early stage of the product lifecycle. Technical feedback at this stage, such as the complexity in getting app permissions or third party integrations not working as expected can save up to a month worth of valuable time which teams often end up losing closer to a full product launch.
Discover new patterns
Once the app is ready and distributed to the users, we begin monitoring the data in an analytics dashboard. This is where shallow apps really shine. We discover new patterns or discarded behaviours in a user's interaction with the product. The popular filter button in the prototype turns out to be just a power-user feature in reality. Or, more users end up sharing their phone numbers over email. These game-changing insights open up new possibilities for the product and help set a direction for the future sooner than later.
A few pointers to watch out for
- A shallow app can only be useful if you are able to release it on time. It requires a shift in the mindset, and often it can be challenging to get the whole team to think shallow about a product because we are perfectionists by design.
- Do not fall for the sunken cost fallacy here. One might be tempted to upgrade a shallow app to an actual one but that is a debt that can prove hard to repay in the long run. Instead, conversion to an actual app should happen in parallel once the product becomes more defined.
- Shallow apps do not need to be thrown away. Instead, they can be a useful playground to run experiments or spikes later in the product lifecycle too.
From a technical standpoint, there is no right or wrong — we choose the simplest thing that will work and push it to the users as quickly as possible. Unlike a prototype, we experiment with an actual product (albeit shallow) in a real environment; because it is not an end product, we iterate multiple times to adopt what works and discard what doesn’t. Every person on the team, from product owners and designers to engineers, come together. All along, we keep in mind that this product is far from the final one.
It bears to keep in mind that a shallow app is not an excuse for badly written software, but instead the shortest path to our users, almost akin to testing the waters before you take a plunge. While this article talks about shallow apps, the concept is applicable to building features in large scale products as well.
If the Obvious Way makes sense to you and you'd want to take your idea or prototype to the next level, we'd love to partner with you. For more information on our engineering ethos and principles, please visit our Engineering Playbook.
