Most enterprises work in lean, agile, waterfall or a cocktail of the three for software development and we all might have experienced some form of them as an Experience (UI/UX) Designer. Lean Startup is a product development methodology started by Eric Ries in 2008 and popularized by his book published in 2011. Eric combined the best of agile and lean practices based on his experience and created this methodology. Lean Startup is not new to the startup world but is increasingly being used at enterprises that want to innovate around their customers. Lean Startup at an enterprise moves R&D experiments in the hands of their users using a minimal viable product (MVP). This brings a product to market faster and cheaper with validated learnings while iterating and releasing constantly in very short cycles.
Innovation is always challenging in a corporate environment. I recently spent a year working with a large company on a project that sought to overcome the innovation challenge by applying Lean Startup methodology. The project goal was to enhance a retail customer experience by creating an online offering for an existing offline product — one with well-established customers and revenue. From my perspective as an Experience Design consultant, the executive-level decision to “use Lean Startup” was a bold move with many advantages, but it was not without hiccups. Here’s what I learned.
Lesson 1: Prepare your team.
Providing orientation to do this methodology is extremely important and our team started with little. In our first Lean Startup workshop; a lean-coach introduced himself, gave a little brief and we started our sprint. Mid-sprint a few developers expressed their concern around on-boarding the idea of throw away code if invalidated by users. After the week concluded two developers left mysteriously. Answers to these questions prior to starting the workshop would’ve helped;
1. Who is a lean coach and why are we learning this methodology?
2. Why was this team chosen?
3. How can this be a part-time project while being assigned to other projects?
4. Why are we doing this project this way and for how long?
Lesson 2: Get consistent support from a Lean Startup expert.
After our first workshop with the lean-coach we got an idea about this methodology. Unfortunately, lean-coach was unavailable after a week. We were expected to read the Lean Startup book, self-organize, develop an MVP and iterate. This was a talented team but it was hard to straddle between old product development habits and new. For a new process like this, some consistent expert guidance was necessary. It took our team a month to realize that a lean-coach was required regularly.
Lesson 3: Build a separate sandbox for lean-startup projects.
It took developers almost 6 months to figure out how to build an MVP outside of regular dev-environment. Existing environment supported bi-monthly releases and it was hard to release anything outside of these cycles.
Our executive wanted a fast way of building a product that by-passed usual corporate procedures. He was being very progressive but the dev-team was so nervous to do things outside the norm because it could compromise security. We tried an external domain, used it for a few initial MVPs and then the lead engineer created a sand-box where we could test inside the company’s firewall. Team was relieved and we could deploy faster leveraging company’s infrastructure.
Lesson 4: It’s not about high quality design, it’s about the product.
When the lean-coach asked us to make something fast and scrappy, I thought it was just for the first week. I presumed I will go back to my usual process of making sketches, do some options, wires, add visuals, get content strategist involved, review with principals and directors, do a couple of iterations and then send them for development after approvals. Fortunately, my design manager was at the lean coaching and she got this methodology. I was concerned about compromising design and she explained how it’s not about the quality. Testing and validating ideas came first, then came quality once they had been validated. It took time to adjust to this way of working but making hi-fidelity designs based on validated learnings is quite amazing. I could think of additional delightful details while observing validation sessions. First product was built off whiteboard sketches, with very little design details. This happened for the first few experiments then moving to medium-fidelity and the quality kept improving. At later stages we were iterating with hi-fidelity designs as those assets got built up.
Lesson 5: MVP can be confused with a PoC, Mock or a prototype.
Whatever fidelity we designed was final and ready to be in front of customers, it either stayed, evolved or was removed. All stages see the light of day and does real business. You could say that it is a pilot, it worked with some folks who didn’t get the concept of an MVP. It’s easy to conflate a proof of concept (PoC), mock or a prototype with MVP. It’s none of those, PoC gathers hints of evidence about the relevance of an idea, mock is for stakeholders to see the vision come to life visually and a prototype is about making sure the product works conceptually. An MVP stays live, working and generating business.
Lesson 6: Co-location is key.
Even though we had telecommuting technologies, designing alongside developers made exponential difference in progress. Especially in corporate environment where it is so easy to get pulled into other meetings and other projects, being co-located ensures working on the same things. Else it added twice the amount of time to do each experiment.
Lesson 7: Use “pivot or persevere” effectively.
We struggled to get online traffic which led us to build an in-store kiosk, since foot traffic was already coming to buy that product. Our focus shifted to an end to end test after this pivot which started guiding our direction. Instead of focusing on online business which was the original value proposition we pivoted to an in-store experience. We started testing technology stability instead of user behavior. We knew implications of our pivot and hoped that once the technology works we can get users to place orders without a snag.
Lesson 8: Team members are business partners and executive is the investor.
It took us time to shed our titles and roles and began thinking like entrepreneurs. I helped with product cataloguing, setting up excel files , planning, managing and shaping business. Developers and product manager got comfortable conducting usability tests. I got comfortable with other team members making last minute UX changes, I knew the tests would show implications and we can iterate. Mindset was very different, the boundaries of roles became blurry.
Lesson 9: Respect enterprise boundaries.
Regardless of our team being an outlier, there were things we couldn’t ignore; security, legal, external vendors and brand image are few of those things. Simple things like sending marketing emails or capturing customer data on our scrappy site was a concern since dealing with such data is sensitive. Support teams accommodated our ad-hoc request and extended a helping hand once they understood how we were on a startup journey. External vendors tried their best to give answers so that we didn’t slow down. Conflicting priorities arose regularly and impacted our cadence but critical business on other projects couldn’t be ignored. Build-measure-learn is a great process for start-ups and they have nothing to lose, but an enterprise has existing business and customers who trust this brand and stakes are higher.
Some of my biggest design challenges were around how to present designs at regular UX team meetings. Every other project was going through the usual review and approval process but I was approving my own decisions. Feedback flowed in these meetings but it was challenging to incorporate UX team’s feedback since the hypotheses for the upcoming sprints were different. Design team injected their ideas based on their experience or what they have done in the past or pointing out inconsistencies with design patterns. Design was off many times because developers made a compromise to build that feature fast and cheap to get it out and test it. Design was evolving but that was a painful process for the rest of the team. It took a lot of courage to deploy half-baked designs.
Lesson 10: Define an end to the Lean Startup process.
Number one question we got was, when will our lean phase end. We all knew that at some point we must get out of experimentation and integrate our solution with the main e-commerce platform. We didn’t have an answer in our case, we said it will end when we know that we have failed or succeeded. Lean Startup allowed us to be creative while making viable solutions.