The grass roots Lean Startup movement continues to pickup traction. As high-profile companies like DropBox and Aardvark have adopted the strategies, the mainstream business press is starting to take notice.

Last week the Wall Street Journal reported its first piece on the topic. My lengthy and productive discussion with the reporter – who had an excellent understanding of the concepts and asked great questions – was unfortunately edited to a single quote. The text is a bit light but the accompanying interview with Eric Ries is an excellent summary of Lean Startup basics.

In my current capacity as an Entrepreneur in Residence I work with dozens of startups, most of them funded by the National Science Foundation or in the DC region. I reference the work of Steve Blank, Eric Ries, Sean Ellis, Dave McClure, Ash Maurya, and others in almost every discussion. Unfortunately many of the concepts are counter-intuitive to popular notions of startups and most entrepreneurs have a difficult time grasping them in one discussion.

If you are a startup entrepreneur, I can’t urge you enough to get connected with the movement. In 5 years it will be almost inconceivable to attempt a startup without these strategies. You’ll increase your odds of success by getting involved as soon as possible.

The DC Lean Startup Circle hosted Eric Ries and Dave McClure Friday night for an entertaining talk about entrepreneurship with local startups.

Thanks TechCocktail for filming the event.

Karma… I made a list of everything bad I’ve ever done and, one by one I’m going to make up for all my mistakes. I’m just trying to be a better person. My name is Earl.

-Jason Lee as Earl Hickey

Generosity: if you give, you get!

-Bill Liao, an ingredient Stone Soup: The Secret Recipe for Making Something from Nothing

In the search for partners, employees, or funding, relationships have always been important in startups; “who-you-know” often separated the best from the good.

But in times past a startup had the capital and time to build relationships. Attend trade shows. Hire a first sales person to make initial office calls.

Come up with an idea, get a good team, pitch enough investor, get some cash. Seems like so long ago, doesn’t it?

We All Need Help

The vast majority of entrepreneurs I work with are – like me – trying to figure out how to build a lean startup, an organization that runs lean by design, not by crisis. An organization that measures progress in terms of customer learning – not hires, lines of working code, or funds raised.

Relationships now matter more than ever because the fastest way to validate an idea is to “get out of the office” and talk to the right people. The cheapest way to get promotion is getting colleagues to spread the word. The best way to avoid a mistake is to get advice from someone who made the same mistake.

We all need help. All of us. And the best way to get help is to give it. Better than buying it.

Enter Karma: Currency in the Lean Startup Era

Karma is in.

For lean startup entrepreneurs, good Karma is better than a Sand Hill Road rolodex.

Don’t believe me? Check out the Lean Startup Circle Google Group. You’ll see a lot of people asking advice, giving advice, sharing experiences, sharing mistakes. You won’t see many people asking “where can I get money?”

I assure you, it was not like this when I started my first company in 1999.

Making Karma

Karma is a funny thing

-Earl Hickey

Indeed, Karma is a funny thing. I don’t know how to quantify it, but I have this odd little Karma account in my head. You probably have one too. I roughly know my Karma balance with people, and I always try to keep it in the black – meaning I’ve helped more than I’ve been helped.

A positive balance keeps a bit of Karma in reserve so it’s there when I need it. I don’t always succeed, I’m sorry to say.

Sometimes this is hard. Like everyone else, my time is the most valuable thing I have. So how in the world can anyone possibly find time to build up Karma?

In a nutshell…

Look for opportunities where you can invest a little time to save someone else a lot

Intros are a great example. All of us have worked somewhere and all of us have relationships that can help other entrepreneurs. Why not spend a few hours reaching out to make an intro for someone?

If you are a developer, look for opportunities where you can help a business-oriented entrepreneur make technical decisions.

If you work in a company, tell your local VCs that you’d be willing to give them any feedback on problems your company has.

Retweet. Leave blog comments. Ask, “how can I help”? Buy their book. Buy their product.

Or if you’re doing a lean startup, post openly about what you’re doing, learning and your mistakes. Ash Maurya is a brilliant example. My Karma account with Ash is a bit in the red; yours probably is too.

Taking Stock of Karma

Do me a favor. Take a moment and think about someone who has helped you on your path to becoming a better entrepreneur and send them some Karma, however small.

I just did that exercise and decided to buy Ash’s product, CloudFire. It is a photo and video sharing tool for busy parents. I don’t have children.

It costs only $44 per year – a lot less than the fantastic advice I got from Ash’s site.

I’m still in the red on my Karma account with Ash, but its a start.

So tell me, to whom are you giving Karma today?

In Four Steps to the Epiphany, Steve Blank covers (pp. 59-60) strategies for making first customer contacts, the process for engaging early potential customers about your idea. I have been sending a lot of introductory Customer Development emails lately and helping several start-ups craft them. Some lessons learned.

Draft the Intro Email – Immediately
If I ask someone to make an intro I always try to send them an email they can forward. It makes it easier for them and helps me control the message. The conversation goes something like:

Wow, thanks for your time. You mentioned that I should talk to X, Y, Z. Can I send you a brief paragraph about me and what I’m doing to make it easier for you to forward?

They ALWAYS say yes. I follow up with an email that day and include “thanks for your time” so that everyone who reads sees that others are talking to me.

Keep it Short
A short email, specific email is more likely to be read – particularly by somebody on a blackberry. A short email also suggests the call will be short. I try to keep them around 5 sentences.

State Emphatically that You are Not Selling
[UPDATE: See comments below. Others suggest that this might be a bad idea. If you write an opinion on this topic please let me know]
I always, always, always tell people – truthfully – that “I’m not selling anything”.

Don’t Create the Appearance of a Sales Call
I focus very generally on the problem and potential solution. Talking about the product in details – or even at all- starts to sound like a pitch even if someone states otherwise.

“I’m working on a start-up/new product idea to help phone companies retain subscribers with Twitter…” is enough detail. My goal is to get the call.

The Subject – Get Closer to Recipient
Following on Steve’s strategies, your subject should say “Referral from X, Follow-up from our meeting at Y”

Don’t Keep Secrets
Obviously I don’t ask for NDAs or give the slightest indication that I don’t trust people. This is easy because (1) I do trust people, and (2) the biggest risk is that I may build the wrong thing.

Beware Cut-And-Paste
A no-brainer, but I recently received an email that had different colors in the text. Obviously a cut-and-paster and it makes me feel less special.

The Magic Word
I’ve found a magic word when asking for a Customer Development call.

Advice.

I try to use that word twice in every email or call. For one thing, it genuinely conveys what I’m asking for. It also suggests – accurately – to people that I want to listen and am ready to change directions. Finally, it gives everyone a reason to take a call.

Who doesn’t want to feel important enough to have people asking them to share their wisdom? I sure do.

Example
(keep in mind this is written in my personal tone – which tends to be less formal and more conversational. This may not work for you)

To: Don Jones
cc: Joe Smith
Subject: Referral from Joe Smith
Hey Don,

Joe may have mentioned that I would drop you quick note to ask for your advice. I’m exploring a start-up idea around making it easier for people carpool using iPhones or other location-based mobile devices. Joe suggested that I talk to you given your passion for reducing carbon emissions through ridesharing.

Do you have time for a quick call this week? I’m not selling anything, just looking for advice.

Joe,

Thanks for your time. You can’t imagine how helpful your advice was to me and hopefully you’ll let me return the favor.

Thanks in advance,
Kevin

It has happened to all of us.

A friend tells you (after first swearing you to secrecy) about a ‘great’ startup idea.

I couldn’t find a pet sitter last week. I’m going to build a social site that allows cat owners to find pet sitters! Did you know there are 100 gazillion cats in the US?

You want to be happy for him, but you can’t resist advising him to consider customer acquisition costs, lifetime value, etc.

Alas, the glimmer in his eyes just won’t fade. He’s going to quit his job and work day and night to start his first company regardless.

Before trying to talk him out of the tree (where his cat and revenue model are hiding), consider entrepreneurism in the larger setting: there are intangible benefits to starting a company that will fail.

Five Intangible Benefits from Startup Failure

5. New Relationships
Entrepreneurs engage investors, other entrepreneurs, and customers – people they won’t meet by just talking about start-up ideas, reading blogs, and attending events. Most entrepreneurs discover that people start approaching them with opportunities once they demonstrate the passion and aptitude for startup work.

4. Refined Business Instinct
Financial pressures have a brutal way of giving an entrepreneur insight into the real issues involved in creating value – customers, sales, relationship building, etc. Most quickly understand why the idea matters so little compared to execution.

3. Casting off the Rookie Label
Since most entrepreneurs fail at their first startup, a failure today prepares us for success tomorrow. There is a big credibility leap between people who try once and those who keep at it.

2. New Skills
Entrepreneurs are forced to learn skills outside of their comfort zone. If you’re a programmer, you’ll learn how hard it is to sell. If your a business guy, you’ll finally see why technology never seems to work like we hope it will. These experiences help us understand the challenges faced by co-workers in future jobs.

But most of all…

1. Failure Teaches Us About Us
Entrepreneurship tests us like few things in life. Jobs are trivially easy in comparison. Capital markets have a brutal way of exposing our own personal flaws in blinding bright neon signs before our eyes – frank feedback you just can’t get any other way.

(Me? I’ve learned to not trust everything I think.)

So smile at your friend, wish him the best, never say “I told you so”, and offer to help out any way that you can. He has taken first step on the most likely road to ultimate success.

Oh, and take him out for a beer in 9 months. He’s going to need it…

Inexperienced developers have one big advantage: they haven’t been programmed to work for perfection and they’re not afriad to make mistakes.
–Neil Callanan, Founder of FitFeud

Summary

Start-up success depends on rapidly figuring out what customers will actually buy, a process that often requires quickly hacking solutions and other bad software practices for the enterprise. Unfortunately most of us get our tech skills from the enterprise – an environment where cutting corners usually causes more long-term problems than benefits. As a profession we need better practices for lean startups

Life as an Enterprise Software Engineer

I learned most of my technical skills in established (i.e. non start-up) companies doing what most engineers do every day: I solved problems. Problems like “figure out a way to speed up the data processing”, or “get the next customer feature into the release.”

I also learned that there are wrong ways to solve problems, that cutting corners on scalability, security, etc. ultimately lead to even bigger problems later.

For example, anyone who has worked in enterprise software has struggled with poorly designed databases that didn’t scale as the application grows. “Why didn’t they solve this problem the right way (TRW) the first time?”, we mutter, wasting money and time cleaning up others’ shortcuts.

Problems, problems, and more problems. A day in the life of 99% of the world’s software engineers is spent coming up with better ways to solve problems.

Problem Solving in the Enterprise

Life as a Startup Hacker

Actually some engineers do work in such an world – lean startups. In startups both the solution and the problem are unknown. Startups don’t know if they have sufficiently defined the problem and the solution until customers vote with their wallets. Eric Ries gave a great presentation on this topic at Web 2.0 Expo 2009.

From Eric's Presentation at Web Expo 2009

When developing software for a startup, you have to forget all the lessons you’ve learned when building enterprise software for large companies or the government: architecture, design, test plans, security scans, performance testing — all that goes out the window.

–Chris Bucchere, Founder of Crowd Campaign and The Social Collective

And therein lies the dilemma: Much of our engineering training in established companies can handicap us in a startup. I’ll give a recent example from my own experience.

My Experience Handicap

Applications built with Ruby on Rails can maintain relational integrity at the application layer – in other words, you don’t need foreign keys in the database. Many experienced developers argue that this is terrible software development practice.

The link above has some great comments:

We had the same argument here at work. We decided to go down the not using foreign key path in hind sight it’s caused us problems

Bugs in the application resulted in garbage in the database that wasn’t discovered until a couple years and terabytes later. One of my colleagues had the joy of spending 6 months as “data garbageman” cleaning up the database. Trust me, you don’t want to go there. Ever.

Yikes.

So how did I design the database for my most recent startup? Having been in situations where poorly managed database relationships resulted in months of rework, I used foreign keys. That was my experience, and I’m guessing the experience of the developers who made the comments above.

Unfortunately I found that foreign keys in my Rails migrations were a constant source of headaches. Moreover, I decided to migrate to Heroku during the project and had to re-write the foreign keys for Postgres instead of MySQL. What did I learn about customers in this process? Nothing.

In retrospect, I believe I followed bad practice for lean startups building working prototypes. Database integrity is an important issue when you have achieved some measure of success.

May I be so blessed to have these type of problems in my next startup.

Lean Startups are Different

Unfortunately I didn’t find great guidelines for dealing with these software development tradeoffs in the Rails community. The voices of experience advocated TRW to design databases for an established company where the problem is known. And in 99% of cases, I believe they right – just not when you don’t know if you’re solving the right problem.

Arguments like “You do/don’t need foreign keys” miss the real point:

Lean Startups need different best practices from enterprise software development

Am I advocating that we ship buggy code and hire high school students for the engineering team? Of course not. What I am suggesting is that we need new best practices like investing in agility and recognizing that the biggest risk is shipping products nobody wants.

Does test coverage allow a company to iterate faster or does the investment in test code just slow down the learning process? And if you decide to write tests, what parts of an application should be tested? Should you even bother to test the View or can you catch 90% of the problems with simple controller tests? Is Selenium really worth the hassle? (it wasn’t for me) RSPEC?

Do you even need design and color? Or can you learn faster by using a minimalist front-end that supports mobile and desktop customers like 43 Actions.

Resources for the Lean Startup Developer

I predict that this essay will be obsolete in a year. Developers are rapidly learning these lessons and beginning to share best practices. Some resources:

The Google Group Lean Startup Circle

The Lean Startup Wiki case studies.

Lean Startup Meetups are happening in DC, San Francisco, Chicago, Boston, Berkeley, New York

And of course, Eric’s blog, the single best source IMHO. At least until he writes a book, something I hope he is considering.

The biggest lesson from my first startup is that need doesn’t equal opportunity
–Patrick Smith, founder MarketHardware

Summary

Vetting the opportunity – not just the market need – is critical for the lean startup. In ManyWheels we successfully used lean approaches to identify a market need and a solution that solved it. In retrospect we could have saved ourselves months of work by asking our customers for early sales commitments. The sale didn’t matter as much as the customer learning from trying to sell.

Last week I decided to move on from ManyWheels, my second start-up. I had a blast, met fantastic people, learned a ton, and can’t wait for my next startup.

(More on “what’s next for Kevin” in the future.)

What follows is a case study I made to share with the lean startup community. If you’re into lean startups, consider joining a lean startup circle meetup such as the one in DC.

Vetting the Market Need

Last year I began working with folks in the automotive market to explore an automated dispatching and routing application for shipping cars. Picture a service like Expedia that allows car dealerships, auctions, rental car agencies, etc. to automatically schedule and dispatch vehicles for transport.

We spent several months talking to everyone in the industry we could find. We learned how relationships and contracts are structured, how data flows, the motivations of different players, and the current shortcomings of existing solutions.

During this process we found a group at one of the largest corporate players in this market – I’ll call them “BigCo” – which provided us tremendous insight into the market needs. The team at BigCo had thought a lot about the problem and cobbled together technologies to find a solution. The situation read like a page out of 4 Steps:

You’re almost there: you’ve found a customer who has such a desperate problem that he has had his own homegrown solution built out of piece parts.

–Steve Blank, 4 Steps to the Epiphany, page 35.

We started proposing solutions to BigCo and screen mockups of different ideas. At first they rejected almost all of our ideas, but after a few iterations they became more interested. Eventually we got to the point where the conversation turned to “when can I get it?” They started taking the idea into new directions beyond what we had envisioned.

We expanded our conversation to other prospective customers and got similarly positive reaction. We reached the point where we felt comfortable building a working prototype.

Prototype Development and Pilot Projects

We asked BigCo if they would be a pilot customer but they advised us – and we agreed – that BigCo was too big for a first customer. We decided to go ahead the build the working prototypes and look pilot customers during development.

We found a smaller-market pilot customer – I’ll call them “SmallCo”. Our working relationship with SmallCo was even better than BigCo. Not only did SmallCo have the same problem and want the same solution, but we worked directly with the owner/operator who was in a position to make purchasing decisions. The SmallCo owner also a leader in industry groups and seemed like a classic earlyvangelist:

We need a word to describe visionary customers – those who will not only spread the good news about unfinished and untested products but also buy them. For that reason I often refer to them as earlyvangelists.

–Steve Blank, 4 Steps to the Epiphany, p. 34.

We cut all but the barest of features and got a working tool in the hands of SmallCo as fast as we could. We seemed to be firing on all cylinders and everyone started getting excited.

The Market Speaks with Real Data

Unfortunately, 2 months into our pilot projects with SmallCo we ran into some real roadblocks: SmallCo had the same needs as BigCo, but SmallCo was too small to be a first customer. We needed a much higher level of market penetration before our solution would be useful for SmallCo.

We needed to first sell to a bigger company – a company like BigCo. We began looking for candidate companies that matched our vision. Unfortunately our search lead us to the conclusion that our solution was not going to be adopted by the market in any timeframe we found acceptable.

Faced with this reality, we decided to move on.

My Key Lean Startup Lesson

In hindsight, we did a lot of things right:
we validated the need before we wrote a line of code,
we cut scope like crazy and got a solution into the market quickly,
we listened and learned and looked for evidence.

Most of all we realized all of this in months rather than years.

However, we failed to do one thing that would have saved us months of time:

We failed to vet the OPPORTUNITY in addition to the market need.

A Simple Way to Vet Opportunity

The biggest mistake I made was in failing to vet the business opportunity and not just the market need. I had a hard time getting myself to talk about pricing and sales early in the process. In my experience, pricing discussions with customers on product concepts can be a huge waste of time with enormous data variability. In retrospect I think there is a better way to approach these discussions than asking people “how much would you pay for…?”

We initially started down the right path in creating a “contract” with BigCo but didn’t continue it long enough. I recently read a great case study on the Google Group Lean Startup Circle:

We visited each potential customer a minimum of twice, if not usually, three times. Each time we would come back with a few more “screenshots” and tell them that development was progressing nicely and ask them for more input. 
We also solicited information as how they were currently solving the problem and how much they paid for their solution.

On the third visit, we pressed those who saw merit in the idea to sign a legally non-binding Letter of Intent. Namely, that they agree to use it for free, if we deliver it to them and it is capable of X, Y and Z. And not only do they use it, but that they intend to purchase if by Y date at X 
price, if it meets their needs.

This is exactly what we should have done. I actually don’t think many customers in this market would sign an LOI. But the conversation would have brought out market insights into volume, financial modeling, and demand that took us months to figure out once we started deploying solutions.

The Key Point

This is the key point of this case and worth emphasizing:

In early product phases the sale doesn’t matter as much as customer learning from trying to sell.

Fortunately we had enough experience to change paths and ask the tough questions once the real data started coming in.

[Author’s notes: I use “we” frequently in this case study to recognize the contributions of a part-time partner, consultants, and advisors who helped get ManyWheels going. I had a lot of help, but the bulk of the operational work of vetting the market, product development, and operations was done by me. I only make this point because team structures are a critical part of startups.]

This [lean startup approach] is the scientific way of building startups. It requires a commitment to learning and thoughtfulness. It is being documented in books like Steve Blank’s Four Steps to the Epiphany and blogs like Eric Ries’ Startup Lessons Learned. It represents the triumph of learning, over the naive startup creation myths we read about in the media.
–Venture Hacks

The critical question isn’t ‘What do your customers want?’ It is ‘How do you KNOW what your customers want?’
–Robert Morton

A lean startup approach is a commitment to entrepreneurial mindset, a recognition that the worst enemy of startups is the illusion of knowledge about what a market wants. In other words, a lean startup entrepreneur needs to accept and try to overcome the limitations of her mind.

In Don’t Believe Everything You Think: The 6 Basic Mistakes We Make in Thinking, Thomas Kida has written a great introductory primer on the basic errors we make in thinking. While most literature on this subject uses very technical and theoretical language such as confirmation bias, Kida presents some basic, useful concepts along with examples from our every day lives.

He calls them a “Six Pack of Problems”:

Kida presents strategies for improving our critical thinking – strategies a lean startup entrepreneur can use in vetting markets.

For instance, I am prone to making the classic entrepreneurial mistake of asking prospective customers questions that serve to confirm what I already want to believe. I need strategies for getting to the truth and saving myself the pain of self delusion.

Consider for a moment, the following answers to How do you KNOW what your customers want?

The X market has a problem with Y, and the technology we’ve been building in our lab will allow them to do Z by…

I have interviewed 10 industry executives about the problem, showed them screenshots of my proposed solution, and confirmed that they are very interested.

5 prospective customers have signed an LOI to test and buy at $X

The first answer is a story – not evidence. The second answer begs for skepticism about how the interviews are conducted. The final answer is a fact.

Which do you find most convincing?

Think arguments between religious zealots are intense? You’ve obviously never witnessed two developers – usually new developers – debate the following question: What is the best programming language?

EVERYTHING IS BETTER IN SMALLTALK!

There is a good reason why a programming debate resembles a dogmatic religious debate: both sides have invested heavily in something that achieves essentially the same goals but cannot point to a specific reason why their choice is “better”.

Of course veteran programmers find these debates tedious because they have seen so much come in and out of fashion. Their usual – and correct – answer is “it depends”.

This ambiguity presents entrepreneurs with a dilemma since ultimately a start-up has to make a decision to bet on a particular technology stack. Just today I saw the following tweet from @RemyMiralles:

Someone on aardvark is asking me “Why is Python so much better than PHP?” There are just different!! it depends on what you need!

Indeed.

But Remy’s answer highlights the dilemma of the entrepreneur committed to pursuing a lean start-up path: By definition you are trying to solve something where both the problem and the solution unknown so you don’t know what you need.

6 months ago I would have attempted to answer this question with some rambling diatribe about scalability, developer cost, frameworks, etc. I now think I have a simpler answer:

The best lean start-up language allows you to iterate your ideas the fastest with the market.

Or, as Eric Ries likes to call it, minimizing total time through the start-up feedback loop:

Eric's core feedback loop for start-ups

My assertion raises the obvious follow-on question: What programming language allows me to iterate the fastest?

Well, if you are truly following a lean approach you probably realize that the choice of dev environment isn’t your top concern. It probably isn’t even in the top 10 for most web-based start-ups these days. You can learn a lot about your customers’ needs with mockups, phone calls, and sketches before you write a line of code.

When you finally are ready to start building the product, the decision might be obvious:

1. If you are a programmer, just pick what you know the best. This isn’t the time to learn Python if you’re already a PHP stud. Get coding, start failing, start learning.

2. If your employees or partners are programmers, just ask them what they can use to iterate the fastest. 99% of the time it is whatever they already know. This isn’t the time to “build it in Erlang for future scalability”. You should be so lucky to have scaling problems some day.

If you’re a “business guy” who plans on completely outsourcing the “programming” to contractors … well … good luck to you. Hopefully you have some idea for how you’re going to pivot. My advice is to find a technical co-founder. You can even use the technology stack choice as a recruiting tool. I’d pick Python to just to get Chris Hagner on the team or Erlang to get Rusty Klophaus even though I’ve never written a line of code in either.

Great developers – not programming languages – build great products.

Finally, if you still don’t know what language to pick, choose Ruby on Rails because it is the best. If you don’t agree, get ready for a public stoning.

Update

Since this writing there appear to be a number of emerging quality tools such as Creately that might do a better job than Visio.

Summary

At ManyWheels we are using Microsoft Visio to reduce our market risk by rapidly, cheaply, and iteratively building clickable web demos for prospective customers using this stencil.  

Risk?  What risk?

Anyone who has been through a start-up or two knows about risks.  Financing risks, team risks, and technology risks are some of the most frequent sources of the entrepreneur’s sleepness nights.

But as technology costs have moved lower and lower one risk dwarfs all others:  market risk.  Market risk is the start-up equivalent of a bridge-to-nowhere: you build a product that nobody wants.  

I try to reduce market risks by challenging my assumptions with two key questions:  ”Am I building something that people want?  How do I know this?”

(The first question is easy to answer.  The second one is a bit tougher…)

So how can I prove to myself that I’m mitigating market risk?

Ways to Mitigate Market Risk

“What’s your problem?”

The most obvious way is to ask prospective customers about their problems.  This process works up to a point; you can get high-level needs and concerns but ultimately most people need to see something to provide specific feedback.

“Do you have 5 hours to read my spec?”

The traditional route is to “write it all down”.  How many prospective customers want to read your detailed 30-page spec?  None that I’ve been talking to.  Good luck.

HTML Mockups – the traditional approach

Another option advocated by 37 signals is “Interface First”:  build mockups in HTML before you start writing any code.  Obviously if you’re very comfortable (and fast) working directly in HTML then go for it.  Personally, I find that even HTML is still too slow because managing and organizing lots of tags can get really tedious.

What I really need

Over the past 6 months I’ve been struggling with a better way to manage this process in my prospective customer conversations.

The perfect tool for me is one that:

• I already know how to use
• is free
• allows me to export in HTML to show to other people
• allows for rapid iteration

Visio to the Rescue…

I know that professional web developers have a lot of different tools for building wireframes.  After a brief search, the option that best fit my needs is the newest version of Microsoft Visio.  It isn’t free, but you can download the trial version from Microsoft and use it for 60 days.

(If you’re ultra-cheap, you can even time the download at the beginning of the month to squeeze a few exta weeks out of the trial.)

You will need the interaction designer’s nail gun (3rd edition), a set of instructions and stencils for building web pages.  You can get an idea of the possible by checking out their demo. 

We’ve been using this tool to do our mockups of ManyWheels with prospective customers.  After a few hours we became proficient with backgrounds, foregrounds, links.  We built a few of our own stencils that allowed for rapid creation of menus, buttons, etc using our color scheme.

The real power of the tool is its ability to allow an entrepreneur to present information differently to different people.  Some people need to see a sequence diagram.  Some just want to see a page.  Others want to see blocks on screens.  All of this is a snap in Visio, plus you can hyperlink it together and publish a web site instantly.

My Experiences with ManyWheels

When we first began engaging the market on our ideas for ManyWheels we started with meetings and phone calls.  We listened.  We asked people about their problems.  We sat next to the people doing the work and asked them about their frustrations.  We tried to get a sense for the market dynamics and what type of solutions might work.  And we learned a ton about the solution we thought we needed to build.

Or so we thought.  

Once we started creating mockups and showing them to prospective customers the conversations took on laser-like focus.  People instantly rejected many of our core ideas and offered alternatives.  Some customers wanted to see high-level data flows to understand how ManyWheels would work in their business.  It took us several iterations like this to get to the point where the conversations moved from “interesting” to “when can I get it”?

(man, those are beautiful words when you’re struggling to identify a solution.)

In Conclusion

My experiences over the last 6 months have reinforced what countless others have already learned:  get a mockup in front of people as soon as you possibly can.  Nothing will focus your conversations and get specific feedback like showing people a possible solution.  Moreover, it sends a message that you’re serious, that this product is really goign to be built, and that you’re thinking critically about the problem.

Fortunately, you don’t need a web designer to do it anymore.  Spend a 1/2 day with Microsoft Visio and the stencils above and you’ll be building worakble mockups in no time.