Maybe you’re an entrepreneur, forging new territory where others fear to go. Or perhaps you’re an intrapreneur, seeking innovation from within the ranks of a large organization. From either perspective, you’ve likely asked yourself: Should I champion bold new software to help my business? And how do I know if I should spend my hard-earned cultural capital, time, and budget on this big idea? The answer is often to build a small version first.
At 303 Software, Agile development and Design Thinking principles guide how we approach building a small solution to validate the big solution. Building small first allows us to test our ideas quickly and inexpensively. We’re fortunate to have a development team that knows how to do this without sacrificing extensibility and scalability. That way, the small solution isn’t throw-away work. If it makes the impact we hope for, we then extend and scale it to become the big solution we always wanted. On the other hand, if it doesn’t make a splash, we can learn why and pivot to another idea. This saves hundreds of thousands, sometimes millions of dollars in development costs.
Here’s how we did it for Colorado’s beloved public radio station, The Colorado Sound.
Focus On One User Problem
Start with the data you have, to test a single user problem.
We always go for a mix of quantitative and qualitative data, including anecdotal data. The Colorado Sound came to 303 Software with a broken app that had been built previously with a different partner. The app was feature-rich, but it often didn’t play the live radio stream. It was also brittle and couldn’t be updated. However, there was enough usage data from that app to indicate that listeners had an appetite for live streaming of the radio station on their mobile devices.
The open question was, what specific features would be needed to attract and retain new listeners on mobile? We partnered with The Colorado Sound to find out. Early reactions to an interactive prototype we designed in InVision Studio helped inform this hypothesis: A native mobile experience focused almost solely on live streaming would be an engaging first iteration that would get the traction needed to justify increasingly robust functionality.
Aim for Lovable
Though limited in scope, the solution should aim to have just enough functionality to be loved by end users.
Our goal was to create a complete experience that can be enhanced in following iterations. For The Colorado Sound, this manifested as a live streaming app focused on resilient streaming and encouraging ticket sales. It was a six week build – natively on both iOS (Swift) and Android (Kotlin), including an interface for Apple and Android watches.
There is the link to the concert calendar, and if the current artist has an upcoming show, there is a scrolling marquee so the user knows when and where and can purchase tickets. The DJs also get to see thumbs up/down feedback on each song. But this was all low hanging fruit. The heart of the app is live streaming.
Measure the Results
A few metrics to consider when judging the early success of your solution may include: downloads totals over time, uninstallations of the app, uses per user, conversions, micro conversions, etc.
The Colorado Sound app saw thousands of downloads across the four platforms in the first month, with steady retention over the next two months. Along with other usage data, it was clear early on that the app was meeting a user need. As simple as it was, the app was indeed getting the traction needed to justify further development. We also noticed there were far more app downloads on one particular platform – handy knowledge to have if we ever needed to prioritize one platform over another.
Going Forth With Data-Driven Confidence
Whether you’re an entrepreneur or an intrapreneur, considering whether to pursue a new software idea can be overwhelming. There’s no need to take a giant leap from a pile of assumptions. Small hops are the way to go, starting with testing a solution to a primary user problem with interactive designs. If feedback is favorable, it will be tempting to add a bunch of cool features. Resist the urge to do this until after you release the simpler solution. That will fuel you with proof of success to then confidently extend and scale the original solution.
