The blog post describes how to use the Lean Startup methodology to develop a real "Who's Who" mail app.

Introduction

I am a new program manager (PM) to the Microsoft ecoSystem team. The team focuses on apps for Office and SharePoint-so it’s natural for us to create mail apps.

I was recently asked to revamp an app project called Who’s Who. This is a Microsoft project to develop an app for Outlook 2013 and Outlook Web Access to visualize personal information and interpersonal relationships.

The team and the project

Our team has one PM, two developers, and two testers. Most app teams have one PM, one developer, and one tester. Some of the challenges we face include:

1. Scenario definition: What to do?
2. Process: How to ensure what we do is correct?
3. Schedule: How to get things done quickly?

About Lean Startup

In our team, we use of Lean Startup methodology for managing apps for Office and SharePoint projects. As mentioned in the article Lean Startup methodology from the official Lean Startup site, “The Lean Startup method teaches you how to drive a startup—how to steer, when to turn, and when to persevere-and grow a business with maximum acceleration.” In a world where things keep changing, the Lean Startup methodology is a good fit. Lean Startup is a good approach for the challenges we face as a team.

Our team has read the book The Lean Startup by Eric Ries, we’ve taken internal training on Lean Startup, and we have great support from managers. Now let’s apply the process to our Who’s Who project.

Run the project fast, with low cost, and deliver frequently

At the beginning, we sat together and went through all the elements and boundary conditions. We agreed that we must iterate the project quickly. The purpose of speed is low cost—everything we do has a fast turnaround. We must deliver regularly to keep the momentum going and let our managers see progress.

So we have the rule of thumb: run the project fast, with low cost, and deliver frequently.

Figuring out what we do

The team agreed that the first challenge is to figure out what to do. We spent one week brainstorming ideas. We investigated similar cases and, for each case, analyzed the pros and cons.

Mock-up and survey

We, the engineers, should not just do whatever we want to do—we need feedback. We used Adobe Photoshop to mock-up ideas and sent them, via emails, to all 70+ people in the ecoSystem team for feedback. We incorporated feedback and then followed up with another round of mock-ups and feedback.

Using email for user feedback is convenient in that it often turns around quickly. However, some people tend to ignore emails. For example, for the second (and last) round of reviews, we received little feedback and the number of feedback received was not large enough to draw conclusions.

Be agile

We brainstormed and decided, instead of emails, we would use another fast and low-cost approach: talking to people directly for feedback. We needed interactions with users to dive deep and observe their needs and requirements. At that time, we decided to add another element to our rule of thumb: agile. Things change-we need to work with agility to keep pace with change.

As shown in figure 1, we are still in the mock-up phase. This allows us to be agile and work out issues before we start coding working prototypes-which is expensive.

Figure 1. Brainstorm ideas

Figure 2 shows our formal mock-ups-after the brainstorming phase:

• (The top-left) Personal: personal information and reporting relationship of the person
• (The top-right) Inter-Personal: how two people relate to each other
• (The bottom-left) Map: people and time information on the same map
• (The bottom-right) Grouping: how many people in a group (grouped by common traits)

Figure 2. Four mock-ups

To ensure that our surveys were broad and conclusive, we talked to several teams and to people with various roles. To minimize cost and risk, we applied Lean Startup again.

Finalizing the UI design

We didn’t have UX researchers-so we started the survey with two to three people. We then expanded to larger groups in different buildings and even at different sites. We synchronized every day to evaluate the survey process and results, and improved the process iteratively.

As shown in figure 3, the face-to-face survey was successful. In two weeks, we talked to more than 40 internal people — directors to entry level positions, from engineering to general admins to sales, from managers to individual contributors, from 20+ year old-timers to new employees — and decided on one solution. People likedthe Personal presentation most (18 first and 4 second votes), then the Map presentation (7 first and 13 second votes).It was clear that Map was the right design (we bypassed the Personal presentation because we already had an app for a similar scenario). It took us about four weeks to finalize the design.

Figure 3. Survey results

Additional challenges

Everything went smooth to this point; the team was motivated. We didn’t realize that another problem was about to emerge.

No money for surveys

We were operating in a traditional IT office environment and failed to execute as a startup with limited resources and funding.

We realized the survey was not diverse enough: it included internal Microsoft China employees, but our major markets include countries like the United States. We applied for funding for a similar survey in the United States by professional UX researchers. However, the application was disapproved. Our investors–the managers–believed that the survey we did was enough and that we should start coding and publish the first working prototype to test the market.

We felt discouraged and embarrassed. We were so focused on perfect surveys that we failed to consider other options.

Demonstrating agility again

The team had a discussion and concluded that scenario studies in the United States was not the right approach. That approach would be costly and time-consuming. We overlooked a more effective option- publishing a working prototype and collecting real user feedback.

Our new plan was to stop survey work and reallocate resources to coding. As we already had a running app similar to the Personal presentation scenario, we decided to work on the second most popular–Map presentation scenario.

Exciting results

According to our estimate, the first version could be running in one week–and we did it. The app was well-received and exceeded our estimates. The number of users using the app scenario was double our estimate. 50% of the users stayed longer than 8.46 seconds, and clicking and hovering on the same elements by the same users after the first visits increased by 50% - 100%, meaning users found the app easy to understand and providing what they needed.

Figure 4. First version of Who’s Who

Conclusion

From the start of the project to first release took about two months. In the two months, we went through brainstorming, researching, creating mock-ups, collecting feedback, and coding the first working prototype. We spent about 30 minutes each day working on issues and reaching consensus. We produced one deliverable each week. Looking back, I am satisfied with the Lean Startup methodology and that we stuck to our rule of thumb: Be fast, low-cost, deliver frequently, and be agile. Our execution of the Lean Startup methodology made this fun and challenging project a great success.

Attribute

This post was written by ecoSystem team PM Kinson Liu, content developer Todd Mackey, and content developer Tony Liu. PM Dorrene Brown provided valuable feedback.