Category: Lean Startup

Iterative Design

Why Iterative Design?

Someone recently asked me “How much time have you usually allotted to paper testing?” I guess I don’t think about it as a process where I allocate some portion of my time to sketching, and another portion dedicated to making prototypes followed by high fidelity comps and production assets. Working that way feels too much like a waterfall process which assumes an orderly progression from concept to product. As a convert to Lean Startup thinking, I know innovative software products don’t come from a predictable and orderly process. As we make things and show them to customers we often learn that we must change the design of the product at a conceptual and structural level, as well as the surface level. How can we create a flexible design process that allows us to keep moving forward fast while allowing course corrections to the design along the way?

Pick the right technique for your situation

In my practice, I’m working with many different design techniques  (solitary and collaborative, low and high fidelity, physical and digital, at a general and detailed level)  throughout the project. I consider the problem I am trying to solve and the kind of feedback I want to gather and choose the method that works best for the situation. In any given week, I might be working on and showing customers: the live product, a generically-styled mock up with fake but realistic data, and a paper prototype as well as using sketches on paper or a whiteboard to think through problems and communicate with my team. Of course, earlier in the project before we have working code we’re using paper and mocks more, but that doesn’t stop once we have a live product. We use them all together as needed.

Three examples

Here are three examples of teams using different methods for iterative design which suit the needs of their team, product and audience.

Carbon Five

Disruptive Innovation using Agile Development and Lean UX
In this blog post Courtney describes a weekly cadence where a balanced team of product owner, designer and developers’ priorities are guided by feedback sessions every week on Friday. In the sessions, the team first shows the working product to potential customers to validate it meets the objectives of the week’s experiment. The pictures in the post show a technique the team used to explore areas where the customer didn’t understand the product. They printed out graphical elements from the product, taped them to a whiteboard and used markers to draw other UI elements. That way the team and the people giving feedback could collaborate on alternative presentations and behaviors quickly and flexibly and save time coding. Cortney  presented more information about working this way at the Lean UX NYC conference in a presentationa called Blending Lean UX and Agile Development.

AppNexus

Suzanne from AppNexus describes how her team used a designer/developer pair and iterative design methods to share an initial concept with users and evolve towards a successful solution. Note that the team had an idea going into the project that was not validated by the users. Through multiple iterations, showing things to users and getting feedback, the team eventually found a great solution. Also note that these technical users required realistic data before they could provide specific feedback about the concept.

Heroku

In this project, Mark and the Heroku team used a prototype built in the Sinatra framework, using spaghetti code and inline styles, with read-only access to a live database.

 

So remember, it isn’t about the technique you use, it’s about the learning you want to gain.

 

Nurturing Lean Startup in the Enterprise

Lean Startup in the Enterprise?

Wow. Lean Startup is really HOT right now. So many new Meetups and conferences and publications and classes and coaches and consultants ready to teach how it’s done. I’m happy to see so many people embrace the concepts, and saddened to see how much of a buzzword “Lean” has become. Similar to Agile, there’s the spirit of the concept (Agile Manifesto) and there’s “going-through-the-motions-agile-with-a-small-a” agile. Writing user stories and doing stand-ups won’t automatically give you the full benefits of Agile. You get the most value when you empower the team and they’re not just going through the motions. Similarly, you can’t apply Lean Startup to any project with any team in any situation and expect to get good results.

We’re reached an inflection point. The Lean Startup movement is passing from a small group of passionate early adopters to the mainstream audience who will metabolize and adapt these practices until they are no longer new and turn into “the way things are done.” We still have the opportunity to share the spirit of Lean Startup and not just teach people to go through the motions. Working in Build-Measure-Learn cycles requires a fundamental change in they way people think and work. Lean Startup changes the way decisions are made in the organization. We value evidence over personal opinion, learning from customers over collecting requirements and build products people actually want. HiPPO won’t let go easily.

I do sincerely believe that Lean Startup is a profoundly different way to work that brings together the best ideas about how digital products are made.  Let’s not blow it.  Here’s my plea to everyone out there speaking and coaching and teaching Lean Startup in the enterprise–help people understand and embrace the philosophy of Lean Startup and not just master the motions.  If we don’t get this right, we run the risk that people will turn away in frustration and miss the benefits that Lean Startup can offer (We tried Baseball and it Didn’t Work).

Common misconceptions about enterprise Lean Startup

Lean Startup is (NOT!) appropriate for all projects.

Lean Startup helps you succeed in a situations of uncertainty– were there’s an unknown market and an unknown solution. If you are refactoring an existing system with an understood audience and a lot of system dependencies, you don’t need Lean Startup, classic Agile is a great approach.

Lean Startup will (NOT!) help you build the product in your head FASTER or CHEAPER.

Don’t burden the team with requirements to deliver specific features or profitability too early in the process. Create a culture that allows experimentation and celebrates failure. Find ways to measure LEARNING and channel it into the EVOLUTION of your product and process. Find product/market fit and make sure you have a identified a problem worth solving and there’s a market for it before you scale up.

An entrepreneurial environment in the enterprise

Give your Lean Startup team the best possible chance for success by creating an entrepreneurial environment inside the enterprise.

Small team with cross-functional skills. People with skills in development, product management & design form the core team (hacker, hustler & hipster). Keep the core team small to maximize collaboration and minimize communication overhead. Support the core with access to subject matter experts who can provide domain expertise and feedback.  As the project grows, add team members with appropriate specialties (e.g. content creation, specialized design and development resources)

Focus. Dedicate the team members for the duration of the project. Team members cannot be doing this part time alongside their other responsibilities. Get the group away from their normal distractions. Move desks so they can sit together. Dedicate a conference room as a project room. Rent them a garage or off-site space.

Embrace an experimental approach. State your hypothesis & recognize assumptions. Be evidence based and determine clear measures to pivot or persevere. This can be hard if there’s a power-over dynamic in the team. Abolish the HiPPO. Good ideas can come from anywhere. There is no truth until the product is delivered to users and validated with satisfaction and revenue.

Fast build-measure-learn cycles. Use just in time design and agile development methods to define, build, deploy, validate and measure continuously. 1-2 weeks “sprint” per experiment is ideal. (For ideas, see “Conversation, Cadence and Culture“)

Frequent interaction with real/actual end users. Don’t just talk to subject matter experts or economic buyers. Continual customer engagement is the engine that drives validation of the evolving product.

Many small experiments. Lean Startup projects in the enterprise can be short (few weeks/month) or longer (several months). An initiative can be as small as one team or several teams in parallel working on related ideas. One way to kick things off is to hold an initial week-long workshop where teams work on different ideas (like a hackathon in the enterprise). A the end the teams present to each other (or the entire company) and the most viable ideas are selected for deeper/longer investigation and development.

Thanks for reading through to the end. Please let me know about YOUR experiences with Lean Startup in the enterprise in the comments below.

Ignite: Lean Startup “I (heart) ugly”

Back in June, I was invited to participate in a session of Ignite: Lean Startup at Pivotal Labs NYC. I gave a short talk about working quickly at low fidelity to help teams create a shared vision, illustrated with some examples from the Knowsy project I worked on with Innovation Games Online.

Ignite is a short-form presentation format similar to pecha-kucha. Speakers are allowed just 20 slides which advance at 20 seconds each, whether you’re ready or not. The format encourages you to be brief, memorable and funny if you can manage it. If you want a challenge to your presentation skills, I recommend the format!

For more talks offered that night, check out the YouTube Playlist.

Our LSM Sketchboard

I had a great time at Lean Startup Machine last weekend and learned a lot. I’d like to give a big shout-out to my collaborators, Gordon Agress, Joshua Haas, Miraya Yao, Ray Schmitz and Sebastian Park who were all enthusiastic, brilliant and cool under pressure. I sincerely appreciate the time and effort that the organizers and mentors contributed to making the event so great. It was amazing to spend the weekend with so many thought leaders in the Lean Startup space.

Rather than one long blog post about the whole event, I’ll start by writing about something our group found really helpful and several people asked me about, our sketchboard (that big brown piece of paper with all the stuff stuck on it).

Picture of team at table, with sketchboard on wall
Our team workspace

The challenge

Lean Startup Machine weekend is intense and not for the faint of heart. In just 48 hours, you form a team, decide on an idea to pursue, and create a product using Lean Startup principles and activities. We needed to engage in customer discovery activities in an asynchronous, and yet coordinated way. How would we keep track of what we were doing and understand patterns as they emerged, without a lot of time for synthesis or reflection? Based on some good experiences I’ve had using sketchboards as part of the LUXr program, I decided to build a sketchboard to help us track our evolving understanding of the problem, the users and their needs.

What was on our sketchboard?

Our sketchboard evolved over the weekend.  We added new information and put revised information on top of older versions, but the structure I established at the beginning held up pretty well. I tried to set it up so it supported telling a story about the problem we were solving. The project name and objectives at the top, problem, ecology and competitive information on the left, user research, segmentation and personas on the right.

Note: you can click on the image to see a larger version of the sketchboard

 

Sketchboard with annotations

 

A – Our project name “DomainMatcher”

B – Our hypothesis, Customer-Problem-Solution statement

C – Competitors in the space

D – Sketch of the ecosystem, with subject matter experts (SMEs) outside buyers and sellers

E/F – This section started out as just two groups domain “sellers” (E)  and domain “buyers” (F) but quickly evolved to visually represent our segmentation theory. Sellers were arranged by low # domains to high # domains held and buyers were arranged into buckets (founders, advertisers, blogger/vanity and flippers). The blue tape indicates we engaged with that person. The provisional personas (Sam the seller and Brenda the buyer) were added once we determined our early adopter targets and drew on elements we heard in our conversations with buyers and sellers.

G – Paper prototype of our buyer Minimum Viable Product v.1

H – A reminder of our goals for the weekend, “Question assumptions” “Iterate” and “Get out of the building.”

How it helped us

I expected that this would help our team keep track of the work to be done and help us create a shared understanding of emerging patterns. I was pleasantly surprised at how quickly people jumped in, contributed their own elements to the board and used it as a focal point for conversation. I believe a healthy sketchboard is owned by the entire team, and isn’t the work of a single person.

Mariya uses the sketchboard to engage with Hiten
Mariya and Ray work with Hiten

An unexpected side-benefit was how it made it easier for us to engage with other people. Several mentors and LSM participants came by, looked at the board and said “OK, I get it, here’s something I can do to help.” It was great to have a visual artifact we could use to quickly orient other people to our project and where we stood, pretty much in real time.

 

More about sketchboards

If you want to see another example of a sketchboard used in a slightly different way (with a nifty video), check out this post from the Adaptive Path blog “Sketchboards: Discover Better + Faster UX Solutions.”

More about Lean Startup Machine

Lean Startup Machine is a weekend long boot-camp where entrepreneurs learn Lean Startup principles through real-world problem solving and coaching from mentors that get it. In 48 hrs, you’ll pitch an idea, form a team and attempt to build something customers actually want. The prize? Cash, mentorship and glory. This is a single weekend that will change how you think about building startups forever.

 

Getting ready for LSM

I’m attending Lean Startup Machine this weekend. Participants were selected via application. At the event we’ll pitch ideas and form small teams of people with business, tech and design skills. (Hooray for cross-functional and collaborative teams!) We’ll learn Lean Startup methods by doing customer discovery and making things together. The program runs Friday night through Sunday eve and there are prizes at the end for the best projects.

I want to get the most out of the experience so I am preparing for it. One aspect is establishing what I personally want to get out of the event. Here’s my objective.

I’m agnostic about the platform and idea I work on this weekend. What matters to me is:
– The team has a good mix of skills
– The team plays well together
– The idea we’re working with is relevant to people who are easily accessable this weekend

LSM participants have many different skill sets and personal objectives. I can’t assume they know me, or anything about what I do. Because of my own objectives, It matters to me that I attract compatible working partners. I created this brief bio and shared it with the group list before the event. It was hard to write because a) in this context, I’m a learner not an expert and b) I do have something to offer and don’t want to under-sell myself. This is what I shared with the group.

Here’s why you would be interested in working with me:
– I am a UXer with big experience and a small ego
– I am great at finding people to talk to and listening to them
– I make quick, lightweight concept sketches (pen/paper)
– I help teams quickly generate ideas and decide on a course of action

My other form of prep is research. I’m reading books and blogs and watching videos. I am trying to figure out “what is lean startup?” “how does it work? “who are the thought leaders?” “where are the examples of people’s experiences with it?”

Observations

  • The Lean Startup movement is young, decentralized and experiential/evolving.
  • Eric Ries identifies it as a movement, not a method or process, and acknowledges participation from prior art and other contributors. (Kent Beck/XP/agile, Steve Blank/Customer Development)
  • It draws on a large existing body of information that requires the learner to know “prior art” or be able to dig back to understand it (e.g. some knowledge of agile terms and practices is assumed).
  • There’s a LOT of amazing great stuff out there if you can find it.

Pain

  • As a person newly interested in the movement, I’ve needed to figure out who are the people who are relevant, then do a lot of research into their blogs/videos (and a little into tech press) to figure out what matters.
  • A lot of the conversation is happening on lists, and at conference proceedings (which aren’t always very well documented)
  • There’s a lot of cross-checking involved (e.g. watching a video, the speaker will reference something I need to go follow up)

What’s useful

  • I find Eric Ries’ “talking head” videos about “what is Lean Startup” “What is a MVP” etc, very helpful. Some of them are informal, some of them are a little more produced, but they’re great for linking/sending to people to say “see, this is what I mean…”
  • I’ve found SocratED helpful, because it pulls together some of these distributed resources in a curated way.
  • I’m finding delicious somewhat helpful, mostly to track my own progress, but somewhat to find other links tagged “lsm” and “lean startup.”
  • Quora hasn’t been very helpful to me yet. Still trying to figure out how to use it effectively.

I’ll post some more impressions after the event, watch this space!