Starting Small: A Startup Guide
Building a minimum viable product before exploring higher-fidelity versions
A little over three months ago I joined the Nudge Rewards team as a Product Designer, with the goal of unifying & organizing our design & development cycle under one roof. Prior to joining the team most of the app’s design work was completed by an outside agency, as new features were added into the platform. Since joining, our team has made the switch to weekly sprint cycles to explore new business opportunities within the app — proving that the feature we ultimately would chose to build actually solves a problem.
The Problem
The guiding rule when building a product seems obvious — build a product that actually solves a problem (and ideally, one that gets people to part with their money). But in reality, identifying the problem and designing the best solution is hard. We see products hit the market all the time that look great and are full of features, but at the core do not solve the users problem. That is why it is important to first validate an idea before investing too much time and money into it (yes, I am looking at you Toronto Star). At Nudge Rewards we try not to overplay our hand and start out small by building a minimum viable product first. Building in sprint cycles allows us to try out things quickly and without having to invest many resources. At the end of the build week we have a strong understanding of the problem we are trying to solve and can move forward by either saying, ‘Yeah, this looks like it could work…move forward with it’ or, ‘That is not exactly what we had envisioned, maybe we can hold off on that for now’.
You usually hear a lot of techies saying, ‘let us build an MVP version first!’ — they are referring to building a product with just enough features to start gathering data about the product before any further development, a minimum viable product (MVP). The term was coined and defined by Frank Robinson, and popularized by Steve Blank, and Eric Ries (The Lean Startup guru himself).
Our team at Nudge Rewards approaches feature-building by first designing a minimum viable product from an existing problem that is ready for customer-validation. We will build the minimum core solution from existing UI components before scoping out how the product might look in the final state. This approach allows our team to start merging smaller chunks of feature code into the main app, and into the hands of our customers for testing and gathering feedback as early as possible. The quicker we collect feedback from our customer-base, the quicker we are able to iterate on that feature and the closer we become to building the best solution we can come up with.
Our Process
When building a feature, a lot of design decisions are made on a daily basis that ultimately decide the final product outcome. A lot of these decisions are typically made based on our personal assumptions and less influenced by real world data. When choosing what we should build next, the easiest choice for us to solve an existing problem and start out small. An existing problem is usually identified by customer and user feedback (so listen to your customers and users and be sure to stay up-to-date with what they are saying, because they will tell you what to build next…for free).
Customer vs. User Validation
When designing software for Enterprise you will often hear whether a product or feature has been ‘customer-validated’ or ‘user-validated’. There is a big difference. Users use and customers buy. The customer making the decision to buy your product is often concerned with purchasing factors such has price, company viability and market leadership — issues that do not pertain to your products usability or user experience. It is important to wrap your mind around the difference between the two and not get them confused when making decisions regarding the product. When deciding what we want to build next, we have to divide our efforts thinking about a feature that leads to both increased customer and user satisfaction. Often times we have already heard in various forms, through in-app reviews, customer discussions and internal reviews, of what customers and users want. For most successful startups this is a critical part of the feedback loop that makes your product functional and helps set the direction of what to build next.
Building With What You Have
You have heard the phrase before, ‘make do with what you have’. The same concept applies to product design when building a feature; often times you do not even need to code or design anything new to prove that what you want to make solves a problem. As a designer, you will instinctively go through your habitual design process to explore and understand the problem to the best of your ability. You might jump out of a product discussion with your team and immediately take some half-drawn idea from your notebook into Sketch and start mocking up a UI. I want to say that this is the wrong approach when designing a feature — especially if your team is limited on resources.
While you spend the time crafting new layouts and polishing UI elements, think about the additional build time you are creating for your development team. Are you harnessing existing, out-of-the-box iOS components, or are you customizing the appearance of the segmented control and toggle switch? Starting small involves leveraging stuff that already exists to your advantage, we are not reinventing the wheel here folks. Your company hired you as a designer to build what is feasible, not to build what makes you proud. Do not be afraid to deliver a design to your team that uses existing UI components, and leave out the custom ones that you built for later.
It is not about right or wrong, it is about allocating team resources effectively. If you had unlimited resources, you would have the ability to make everything ideal. But in the absence of unlimited resources you have to allocate smartly. Rather than worry about the shade of lipstick on the pig, let us make sure that the pig is edible first. I could spend time customizing UIKit elements that our developers will have to go and build out, or I could use the existing UISegmentedControl that developers already have built in the UIKit. When refining these elements back down to their core, I will create a list of the components that we strip out from the minimum viable product build, and save them for a feature retrospective after it is released. These components become perfect candidates for a fast follow.
Fast Follows
When starting a new sprint cycle we may opt to revisit a recent feature release that still has some areas for improvement. Once we have shipped a feature and got it into the hands of our users, we have a strong indication whether we should continue allocating our resources to. If the feedback is generally positive and we see more areas for growth, we can grab that list we saved in the last section of the components we decided to strip out for MVP and see the areas we can iterate on and fold those changes back into the main feature. Otherwise, if the feedback is not so positive, we will revisit the drawing board and try to figure out our next problem to solve.
Recap
- Before allocating all of your teams resources to one problem, first build a minimum viable product for validation
- Do not be afraid to create your minimum viable product designs with existing UI elements
- Your team wants to create something feasible, do that before creating something that makes you proud
I’d like to thank the entire team for their efforts, you can read about our other endeavours at https://medium.com/hitech-nudge-rewards.
