Believing in the Iterative Process of App Development
This article is written for EHK by Willson Mock, software developer, designer, and co-founder at Altitude Labs. Altitude Labs is a Silicon Valley styled web and mobile development consultancy in Hong Kong.
One key question in building product: Are users in your identified market actually using your product?
“So here’s what my product is … and it has to have feature A, B, C … Z by launch”
This comment and its variants are one of the most common phrases we hear from entrepreneur and enterprise clients. And it makes sense – they’ve been trained all throughout their careers to think in terms of what the final results should be. But for app development and launching a successful product, you have to fight against this pattern of thinking. Instead, always come back to our one criterion for measuring success: for your identified market users, what are the absolute core features that will address their need or solve their problem?
An exercise we find extremely helpful with our clients is something we mirrored from the management consulting industry: brainstorming and generating different user stories on:
1. What is the problem
2. Who is facing the problem
3. What is your proposed solution to the problem
4. What metric are you using to measure how successful your solution is
The end result of this exercise is usually something along the lines of this statement:
“We believe [Identified User Market] have a problem [Doing This]. With [Our Proposed Solution], we can help them address this problem. If we’re successful, we should expect to see [Some Change in Metric].”
From here, we work with our clients to determine what the absolute core features are in their app that will address the above statement.
“But these are really all the features that my product will need now.”
We understand it’s difficult for many of our clients to break from this thought pattern. But it’s important to remember the fallacy here, and that’s to presume that you know exactly what your users what and how they will use your product. Even with domain expertise, our clients often come up with an idea and stick with it without going back to our main gauge of success: the end users.
Regarding features that their initial MVP should have, we work with our clients to come up with a list of all the features (no matter how extravagant or crazy they sound) they want their product to have, and then we run through an exercise to:
Eliminate features that are don’t meet some benchmark (i.e. budget, feasibility, etc)
Prioritize the remaining features based on our initial best guess of the target market’s needs
Fighting the common thought of needing all these features now, we get into the habit of prioritizing all the features, and always executing the highest priority ones first. And after launching each feature, we always go back to our measuring stick, which is our users and getting their feedback to determine whether these features are getting the results we expected.
While it’s difficult to trust this process, our experience is that this iterative process of launching features, getting customer feedback, pivoting or coming up with next features to launch, and repeating is the most effective way to staying in touch with your end users and ultimately delivering a product that meets their needs.
“Isn’t a MVP a cheaper product? Why would I want that?”
Perception is one of the most difficult obstacles to overcome, and for some reason, whenever clients hear minimum viable product, they automatically register that as an inferior version of their ‘perfect’ product. However, developing a MVP is far from that; in fact, it’s based on the idea of building a smarter product and application given the limited resources you have: time and money.
We often educate our clients by showing them examples of wireframes and actual released applications, and the similarities and differences between the two. Obviously, the released application looks much more compelling and polished than the versions drawn up in wireframes. However, in terms of features and functionality, the two are actual very similar. But that’s the point – during the application development lifecycle, we want to focus on the features that will be most important to the end users and consistently aim to develop those first. Being visual people, it’s easy for clients to get caught up in how wireframes may look barebones and somehow that translates to the application itself being barebones and not fitting their end user’s needs.
We continually educate our clients by helping them focus on their initial hypothesis of how users will use their product. Building a minimum viable product doesn’t mean that we sacrifice on the polish and look of the application. Instead, we’re constantly pushing only the most relevant features out in an incremental fashion and asking our end users for feedback. And from our experience, when you start trusting in the iterative process for app development, you won’t end up building the ‘perfect’ product – instead, you’ll end up building a product that’s catered for the users in your market and have the highest likelihood for launching a successful product.