According to research by QSM, the average software project takes almost a year to complete, and includes dozens of unneeded and unused, yet complex features. So how did our tiny, fully remote, and distributed team managed to overcome these obstacles and take a new idea from birth to a fully functional product loved by thousands of users in just a few short months? It’s not a secret, and it has more to do with people than it does with technology.
How It All Started
In October 2019, we partnered with our large non-profit client to narrow down opportunities in the financial health space and to create a solution that solves customers’ most painful problems. This solution will eventually be a part of a full mission-based platform to help struggling American consumers manage their finances. We had already aligned on the overall vision, goals, and high-level opportunities to explore. We had also tested ideas with the users and delivered the first content-based solution MVP (Minimum Viable Product). Building on that success, our new goal was to narrow down and realize our next big opportunity within the space, and to create a more interactive MDP (Minimum Delightful Product) in just a few short months.
The Process
First, we held a series of workshops and meetings to review what we’d already discovered, and to explicitly agree on the next solution’s high level vision, scope and target customer. Then, we agreed on our goals and research objectives, such as learning about consumers’ pain points and levers, testing our riskiest assumptions, and gaining customer perspectives on existing and emerging concepts.
We also mapped the broad areas of potential opportunities in terms of their impact and fit for the client’s vision, assets and competitive landscape along with consumer benefit. This helped to identify several areas to research as we started working on potential solutions to validate with our customers.
The next sections describe how we used design thinking, ruthless prioritization and process efficiencies to aid speedy discovery and product definition. In this way, we delivered the best possible solution with the smallest investments of time, code, and money.
The Key to Confidence: Evidence!
Our key question was, of course: “what’s worth doing?”. Knowing that our timelines and team resources were very limited, we had to feel confident that our tool would solve a real problem for people. And, we had to deliver this solution using the minimum amount of team effort and time. So, we gathered real evidence and used design thinking to create solutions that were simple to make and effective for users.
First, we ran a series of interviews in order to discover the most painful problems in the space we had chosen, and to understand user satisfaction with current solutions. We also ran surveys to validate our qualitative results and to help us prioritize use cases according to impact and concern.
Some problem-space questions we asked that we found particularly helpful:
- What steps did you take when dealing with this problem?
- What impact does this problem have on your life?
- Have you found any solutions to this problem so far? What were they?
- How did that solution work for you?
- How are you feeling about your situation now?
We also showed early designs for a product which might solve these problems. We asked things like:
- Would this solution make a difference for you? How? (Or, why not?)
- How does it feel to use, compared to (solution you mentioned)?
- Which part of this felt the most valuable to you?
- If you could change anything about this, what would you change? Why?
- Would you like to sign up for a notification, so you know when this is available?
How did we know we were ready to start? Our research gave us the key things needed to have confidence in our product:
- ✅ Empathy and understanding of real user problems
- ✅ Knowledge about which features would be the most effective way to solve the problems
- ✅ Evidence of interest in signing up for the solution we were drafting
We didn’t stop there. As we worked, we ran our prototypes by customers at every stage to make sure our solutions were valuable while remaining easier to use than competing products. These sessions allowed us to quickly validate our designs, cut or backlog features that were not as valuable, and reveal new feature opportunities.
As we observed our users interacting with releases of our product, we collected insights into their experience and built the experience maps. These insights helped us visualize where things could be improved, and where new opportunities may lie.
Ultimately, we realized users needed a product that would not just provide a set of features, but address a much bigger challenge – changing destructive user behaviors. The nuances from our research allowed us to get to the core beliefs and fears of our users. From there we could challenge their assumptions and lead them, through the product experience, to better behaviors.
Setting the Focus and Getting Stuff Done
Our original scope was pretty broad, so we needed to prioritize ruthlessly on delivering:
- Solutions to the most valuable problems
- In the simplest way possible.
While “a)” was validated with the users along the way, “b)” needed extensive discussions with engineering and architectural leads well before epics were written and any coding was done.
We then created an original MVP concept with a list of ‘must have’ and ‘nice to have’ features based on our research as well as impact and effort estimates. With this focused concept, we propagated shared understanding that further cuts might be advisable as more information emerged and deadlines approached. In fact, many items from that original MVP concept ended up being cut out or postponed to the next stage, as our understanding of effort was deepened with more engineering work, or as we saw that customers didn’t see the feature as central to their experience.
We eventually expanded the MVP concept to the MDP (Minimum Delightful Product), which is a concept widely used in Silicon Valley to emphasize the importance of excellent user experience in addition to lean scope. We focused on MDP to make sure we provide the best possible advice and to align with our client’s ‘no-harm’ principle, especially relevant in the financial health space. As we continued building out capabilities, our focus on the concepts described in this article helped us deliver the most value in the least amount of time.
Shortcuts and Efficiencies
In order to utilize our small team in the most efficient manner, we also took some thoughtful product, engineering, and DevOps shortcuts. For example, we opted out of spending our time precisely sizing the features. Precise sizing is done in the Scrum method of Agile development in order to reduce timing uncertainty. Instead we used the Kanban method with less time spent in up-front estimation, and prioritized our backlog in real time while making sure we were only working on the most important things. This method provided less certainty around exact efforts and iteration timing, but improved our efficiency greatly. It also allowed us to better address last minute client requests as part of our process.
We also invested in identifying blockers and dependent tasks early by tech reviewing the upcoming features and by building proofs of concept where needed. This habit reinforced a discipline of earlier requirements on the product side as well as allowed engineers to work in parallel on the same features simultaneously, utilizing all of the team members. Lastly, investing in automated tests allowed us to move quickly with less risk of breaking existing features. Automated testing also served as ‘live documentation’ that helped everyone understand the app behavior without having to create separate documentation.
Our engineers also instituted a daily ‘development sync’ which helped our fully remote and time asynchronous team to peer review their implementation, gain clarity on Acceptance Criteria and resolve concerns real-time. We also spent a lot less time in meetings than customary by using Slack, and by empowering folks to proceed with assumptions, to be remedied later if desired.
Lastly, we continuously reviewed our product and planning processes for efficiency and made sure that priority communication was crystal clear to all. Frequent retrospectives also helped us stay on track and improve in real-time. In total, these positive habits allowed us to achieve our outcomes with less time, code, and money.
Success
As a result of following the practices described in this article, we were able to deliver a lot more than a Minimum Viable Product (MVP) and in a shorter amount of time. We delivered a fully functional Minimum Delightful Product (MDP) to production in just 3 months after starting development, and less than 6 months after the original idea!
On-site survey indicates that over 80% of customers are finding the new app easy to use and helpful in managing their challenging financial situations, with the majority finding it ‘very helpful’. These are exceptionally good numbers for the first release!
In addition to releasing only the most valuable features and delivering ahead of schedule, the code is easy to maintain and scale. Going forward, we continue to monitor success via usability tests, on-site surveys, user interviews and Google Analytics data. Early results are extremely encouraging and show how our approach can help a small team deliver on the big value.
