Be wrong first.
Getting satisfaction out of shipping MVP’s
I work at Oscar Health Insurance, alongside a fantastic 60 person product engineering and design organization. A few smart guys founded Oscar back in 2013 when it seemed like a collision of events, both good and bad, pointed towards a need to disrupt the healthcare space. What they knew then was that building an insurance company, in other words, the people who control the money, was the best way of shaking up a disaster of an industry. I’ve been with Oscar a few years now and while we knew we had to check a lot of boxes in order to become the disruptor we promised investors, I’m not sure anyone could have fathomed how much of a tall order building such a machine would be.
I’ve had a total blast working at Oscar and I’m most proud of the work my team has put into building MVP’s (minimum viable products). Since I began in 2014, I’ve helped research and design a CRM, telemedicine platform, a robust healthcare search engine, physician tools including a patient electronic records system, countless customer service tools, appointment scheduling, and more recently, a new look at intelligently personalized doctor profiles. All of these products were first shipped in a rough, duck taped form that we tracked and improved over time (don’t worry — security around health data was never “duck taped”). As designers, I think we often become too attached to the most aspirational, feature rich solutions — not because we like frills but because in our minds, this system (solution) worked and it made the user act and feel a certain way. As a result, it’s easy to butt heads with PMs and engineers as they dismantle our solutions beyond recognition. In the following few paragraphs I’ll talk about the challenges I’ve faced shipping these types of features and the inherent benefits of taking such a dive.
The hard part
“The lighting rod effect”. Fact: you’re likely the first team at your company to build against a particular user or business problem. If your company has any sort of visibility into the product team’s roadmap, you better believe that you’ll have a “captive audience” and by captive I mean lots of people complaining about the problem, suggesting solutions, and critiquing your team’s approach. This is a good thing. It means you are working on something important. Take the scrutiny in stride and identify potential allies who could become contributors to the project.
Research required. Strong MVP teams, entering uncharted territories thrive on good research. That includes traditional design research methodologies like contextual inquiry, interviews, surveys, and user testing but also quantitative product analytics. Learning to monkey around in Mixpanel, or any other business intelligence platform, can be one of the most gratifying experiences for a designer. It’s impossible not to learn something new about your product or user behavior. Use what data you have to help formulate hypotheses about how new features might perform. For example, find out where users are spending most of their time today and consider how your MVP can hook into these pre existing workflows.
I also do a ton of benchmarking. As special as you think your interaction design problem is, I guarantee someone has already solved, or at least attempted it. I check out pttrns.com, www.useronboard.com, www.mobile-patterns.com, ‘More like this’ on Pinterest, some dribbble, the ‘Related’ tab in the iTunes app store, and any Google app — these guys have done it all — very well.
Compromise, concede, barter, and when necessary, fight . The absolute hardest thing for a designer shipping an MVP is working with PMs and engineers to whittle down the concept to its smallest form. It’s truly a (heartbreaking) form of art. Learn why features are being snipped and stay on top of the analytics that could get them prioritized in a v2 (stay tuned for more on feature prioritization). Keep aspirational versions of the feature well documented and socialize them with your team frequently. Designers are uniquely poised to provide this type of lens into the future. Finally, sometimes you just have to fight. If you did your research properly, you’ll be an expert in the problem and it’s a designer’s job to advocate for the user at all costs.
The fun part
You’re the expert. In being some of the first people to tackle a particular problem, you’ll quickly find your team becoming experts in the issues, solutions, and just about everything in between.
Boost engagement with other teams’ features. If you’ve built a new feature that provides in-roads to other parts of your app or website, you’ll make a few friends along the way. Hopefully, in the future they’ll be apt to do the same for you.
Fast feedback. An MVP, by definition, exists to immediately affect user behavior. If you’ve properly tracked your feature, you’ll quickly start to see completely new signals from the product. Paul Adams, one of my all time favorite product people, wrote a great launch email to his team about this. It’s then your team’s responsibility to parse whether the signals you are tracking are indicating positive or negative user behaviors. Either way, you’re in for instantaneous feedback. A well tracked feature can help build the case for further investment, regardless of how well it performs in the MVP state ie. secure resources to build that thing that got cut in the first version. A poorly performing feature is more likely to get worked on than one without any tracking at all.
MVP’s in a lot of ways are at complete odds with how a designer’s mind works. They often jettison the delight, the nuanced, and aspects we’ve come to accept as “standard” in other robust apps. This is all a part of the process. Stay on top of the features that didn’t make it and keep your team abreast of your “north star” concept. Pull back the covers on your process and expose your team to the all the twists and turns. You’ll quickly start to find that the design process itself is much like the MVP process — a meandering journey of experimentation and being wrong as fast as possible.
Questions for the reader
- The “connector” features within an MVP, in other words the parts that link to other parts of the app, sometimes don’t fall within scope. How do you prioritize the parts of a feature that do not directly improve your core KPI’s?
- What are the best resources out there for becoming a more data informed designer?
- How long are your iteration cycles ie. how often do you ship updates to a feature?
Successful techniques for healthcare UX design