Need Your Team To Move Faster?

My recent executive conversations have a common theme - speed.  Specifically, they all want their teams to move faster.unknown.gif

For example, one client acknowledged they were still trying to figure out how to better prioritize so they could focus on executing at a pace they’ve never moved at before.  They need to release products faster so they can learn from the market faster, but the team’s focus and sense of urgency is not where it needs to be.

To move faster, we need to adopt more flexible operating structures but we also need to change our standards of what ‘done’ looks like.

Take the iPhone. It launched in 2007 and revolutionized the mobile phone industry. But, check your software. Mine’s up to version 12.3.1. That means in the 12 years since it was released, at least one new version of the operating system (iOS) has been released (though, all Apple users know there are multiple fixes released in any given year). Let’s not forget the rumors that Apple will release the iPhone 11 with iOS 13 later this year.  That’s a lot of new versions of the same product in just 12 years!

The point is that our products do not have to be perfect to go to market. They should be good; they just don’t have to be ‘done’.   I love to remind my clients of the famous quote by Reid Hoffman, the founder of LinkedIn: 

“If you are not embarrassed by the first version of your product, you've launched too late.”

This quote is so important because the best way to see if an innovation is a good idea is to see if the market will buy or use it.  This means adopting a test and learn, iterative product development process and becoming comfortable releasing products before they are 100% finished.

 

 

 

Shipping Beats Perfection

Khan Academy, a vanguard innovator in online learning, said it best: “shipping is better than perfection.”[1] At Khan, the team prioritizes getting their online courses launched on their site, over getting the most perfect version of the courses out there. Their target market, namely students, are craving knowledge. So, Khan delivers a good course (that is still well-built on the tech side), but with lots of room for improvement. Then, they listen to what their users tell them about their experience with the course. That way their next iteration delivers what the users actually want and need.

I know that this idea may be anxiety inducing to many executives. Afterall, we probably didn’t become CEOs by not being at least a little perfectionist. But we can still deliver a quality product fast. We just have to reframe our thinking to include the notion that we are building something good in order to make it great.

Defining Your Minimum Viable Product

We’ll get started by defining our “Minimum Viable Product.”

“The MVP is the smallest experiment that either proves or disproves [your] assumptions about a business idea.” [2]

 –Jerry Cao, UXPin

The concept of Minimum Viable Product (MVP) comes from the “The Lean Startup” by Eric Ries. At its core, MVP is the easiest product to build that meets our assumptions about our customers’ needs and allows us to gather as much data as possible to confirm (or correct) those assumptions. Ries calls it a “build, measure, learn loop.” [3]  Breaking that down we:

  • “build” a product we think customers want;
  • “measure” if and how they use it;
  • “learn” from what costumers do and say about the product; then,
  • “loop” back to the beginning to build again.

The trick is ensuring that whatever you build, it is able to meet the customer need you have identified.  The often cited example is if the customer need is “transportation from point A to point B” you build a scooter or bicycle, rather than just building a car chassis with no wheels. [4] 

Quickly Learning from Your MVP

A key point to remember is that we don’t define and release an MVP without a vision for where we want our product to go in the future. We use product roadmaps to set the course from MVP to future product releases. We chart our long-term product direction out at the MVP stage and then update roadmap frequently based on what we learn from the build, measure, learn loop. 

This also means we need clear and detailed testing plans for what we need to learn from our first few releases. It’ll be important to have a process for documenting our open questions and our hypotheses and defining how we will test them. Additionally, a well-defined process for capturing the data we collect and for revisiting our hypotheses will make certain we can learn and adapt as we go. 

It’s really important that our testing focuses on how we can better meet customer needs, not just how we can improve features of our product. This means that our experiments should focus on things such as why the customer uses the product, how they used it, what they would do differently, etc., in addition to questions about the ease of use and overall functionality.

Making the Rest of the Organization Comfortable with an MVP Approach

Finally, we cannot forget to be very explicit with our sales teams and our customers that this is an iterative process. The things to keep in mind here:

  • clearly communicate to sales what the roadmap looks like, so they know what is coming and when; and
  • explain why we structured the MVP the way we did, so they know the customer problem the product solves right now.

Lean product design and changing our standards of what ‘done’ looks like is a new way of working for many of us. But the payoff can be huge. A recent survey of 170 executives who work in R&D, strategy, and new product development roles at large public companies found agreement on several benefits of taking a Lean product design type of approach:

  1. Speed! A faster cycle time for developing ideas.
  2. Making decisions based on evidence and data, rather than executives’ instincts.
  3. Better-quality feedback from customers and stakeholders, often because you’re asking them to actually buy something, rather than just spout opinions in a focus group.
  4. “Getting out of the building” to speak to and observe real customers and stakeholders.
  5. More flexibility about making changes to ideas as they progress from concept to “minimum viable product” to finished product.

A Final Thought About Test-and-Learn

Many of us struggle adopting this approach because it takes changing our standards of what done looks like. It also takes building our capabilities to quickly collect, aggregate, interpret and apply customer feedback to the MVP (and future versions) to evolve our product as quickly as possible. 

Testing and learning, at speed, takes a lot of work. It takes highly specialized analytical skills and a deep understanding of smart product development. This may be where we really need outside help.  Don’t forget our team at Vecteris has decades of experience working with companies as they quickly bring products to market and are highly-skilled at the analysis you need to quickly assess customer needs. Don't hesitate to reach out to see how we can help.

 

[1]“Shipping Beats Perfection” Explained by Ben Kamens

 

[2] MVP vs MDP = Viability vs Delight. What You Really Need? By Oleksii Shevchenko

 

[3] MVP vs MDP = Viability vs Delight. What You Really Need? By Oleksii Shevchenko

 

[4] https://twitter.com/usertesting/status/683435632425713664