John Prendergast

I'm in a startup, now what?

I got a simple email question the other day.

Great to have met you last night. Have any advice for someone like me who just joined a startup?

My stream of consciousness response

Interesting question. 

Be a killer in your role. Find ways to do more. Ignore your title or specific role and help solve the company's key challenges.  The thing is, in a startup in particular, everyone's job is to go looking for trouble. Go find important things that need to get done. Find the creative ways to move things forward 10x faster. Ask forgiveness, not permission. Be smart, run like hell.

Not sure that's what you were looking for but it's what came to mind.

So if you're in a startup or any small company, go looking for trouble.

Be a hooligan to every problem.

Kick its ass and leave it the gutter.

 

Keys to Real Innovation from Steve Jobs - Reprinted from Guy Kawasaki's G+

I loved this so much, I just had to share it.

What I Learned From Steve Jobs


Many people have explained what one can learn from Steve Jobs. But few, if any, of these people have been inside the tent and experienced first hand what it was like to work with him. I don’t want any lessons to be lost or forgotten, so here is my list of the top twelve lessons that I learned from Steve Jobs.

Experts are clueless.

Experts—journalists, analysts, consultants, bankers, and gurus can’t “do” so they “advise.” They can tell you what is wrong with your product, but they cannot make a great one. They can tell you how to sell something, but they cannot sell it themselves. They can tell you how to create great teams, but they only manage a secretary. For example, the experts told us that the two biggest shortcomings of Macintosh in the mid 1980s was the lack of a daisy-wheel printer driver and Lotus 1-2-3; another advice gem from the experts was to buy Compaq. Hear what experts say, but don’t always listen to them.

Customers cannot tell you what they need.

“Apple market research” is an oxymoron. The Apple focus group was the right hemisphere of Steve’s brain talking to the left one. If you ask customers what they want, they will tell you, “Better, faster, and cheaper”—that is, better sameness, not revolutionary change. They can only describe their desires in terms of what they are already using—around the time of the introduction of Macintosh, all people said they wanted was better, faster, and cheaper MS-DOS machines. The richest vein for tech startups is creating the product that you want to use—that’s what Steve and Woz did.

Jump to the next curve.

Big wins happen when you go beyond better sameness. The best daisy-wheel printer companies were introducing new fonts in more sizes. Apple introduced the next curve: laser printing. Think of ice harvesters, ice factories, and refrigerator companies. Ice 1.0, 2.0, and 3.0. Are you still harvesting ice during the winter from a frozen pond?

The biggest challenges beget best work.

I lived in fear that Steve would tell me that I, or my work, was crap. In public. This fear was a big challenge. Competing with IBM and then Microsoft was a big challenge. Changing the world was a big challenge. I, and Apple employees before me and after me, did their best work because we had to do our best work to meet the big challenges.

Design counts.

Steve drove people nuts with his design demands—some shades of black weren’t black enough. Mere mortals think that black is black, and that a trash can is a trash can. Steve was such a perfectionist—a perfectionist Beyond: Thunderdome—and lo and behold he was right: some people care about design and many people at least sense it. Maybe not everyone, but the important ones.

You can’t go wrong with big graphics and big fonts.

Take a look at Steve’s slides. The font is sixty points. There’s usually one big screenshot or graphic. Look at other tech speaker’s slides—even the ones who have seen Steve in action. The font is eight points, and there are no graphics. So many people say that Steve was the world’s greatest product introduction guy..don’t you wonder why more people don’t copy his style?

Changing your mind is a sign of intelligence.

When Apple first shipped the iPhone there was no such thing as apps. Apps, Steve decreed, were a bad thing because you never know what they could be doing to your phone. Safari web apps were the way to go until six months later when Steve decided, or someone convinced Steve, that apps were the way to go—but of course. Duh! Apple came a long way in a short time from Safari web apps to “there’s an app for that.”

“Value” is different from “price.”

Woe unto you if you decide everything based on price. Even more woe unto you if you compete solely on price. Price is not all that matters—what is important, at least to some people, is value. And value takes into account training, support, and the intrinsic joy of using the best tool that’s made. It’s pretty safe to say that no one buys Apple products because of their low price.

A players hire A+ players.

Actually, Steve believed that A players hire A players—that is people who are as good as they are. I refined this slightly—my theory is that A players hire people even better than themselves. It’s clear, though, that B players hire C players so they can feel superior to them, and C players hire D players. If you start hiring B players, expect what Steve called “the bozo explosion” to happen in your organization.

Readl CEOs demo.

Steve Jobs could demo a pod, pad, phone, and Mac two to three times a year with millions of people watching, why is it that many CEOs call upon their vice-president of engineering to do a product demo? Maybe it’s to show that there’s a team effort in play. Maybe. It’s more likely that the CEO doesn’t understand what his/her company is making well enough to explain it. How pathetic is that?

Real CEOs ship.

For all his perfectionism, Steve could ship. Maybe the product wasn’t perfect every time, but it was almost always great enough to go. The lesson is that Steve wasn’t tinkering for the sake of tinkering—he had a goal: shipping and achieving worldwide domination of existing markets or creation of new markets. Apple is an engineering-centric company, not a research-centric one. Which would you rather be: Apple or Xerox PARC?

Marketing boils down to providing unique value.

Think of a 2 x 2 matrix. The vertical axis measures how your product differs from the competition. The horizontal axis measures the value of your product. Bottom right: valuable but not unique—you’ll have to compete on price. Top left: unique but not valuable—you’ll own a market that doesn’t exist. Bottom left: not unique and not value—you’re a bozo. Top right: unique and valuable—this is where you make margin, money, and history. For example, the iPod was unique and valuable because it was the only way to legally, inexpensively, and easily download music from the six biggest record labels. 

Bonus: Some things need to be believed to be seen. When you are jumping curves, defying/ignoring the experts, facing off against big challenges, obsessing about design, and focusing on unique value, you will need to convince people to believe in what you are doing in order to see your efforts come to fruition. People needed to believe in Macintosh to see it become real. Ditto for iPod, iPhone, and iPad. Not everyone will believe—that’s okay. But the starting point of changing the world is changing a few minds. This is the greatest lesson of all that I learned from Steve.

Reprinted from Guy's G+ here:  http://bit.ly/nGC93V 

A Meeting with Young Entrepreneurs

I got a call from one of the mass challenge finalists a few weeks ago. They were planning a new Sushi restaurant concept and were hoping I could help. I think they got more than they bargained for. Here's how they saw it: 

I couldn’t help but laugh. Not a “hahaha- you’re so witty!” laugh. It was a “hahaha- are you serious? I just spent the last year believing steadfastly in something, and you just made me go back and question everything….asshole!” – you know, one of those laughs.

A bit of background might be useful. My first big entrepreneurial venture was as one of the earliest Boston Chicken (Market) franchisees. While I was still in college I convinced my parents to take mortgage on their house to give me the money to start the business along with 2 partners. Though it worked out, it's not a recommended financing strategy. It did however, give me an accute appreciation for how every dollar is spent in a new business, particularly a restaurant. After I sold that business, I managed a 65 restaurant business unit for Allied Domecq (Dunkin Donuts & Baskin Robbins). That gave me a lot of experience with scaling a restaurant business. 

Fast forward, I'm an advocate for the lean startup approach and think a lot about how the approach can be used ouside of software where I apply it at my company Blueleaf. With that backdrop, the Sabi Sushi guys stroll into my office. Man was I fired up.

Here's how Shaan Puri describes the first part of the conversation:

John P. – I love your concept, obviously, that’s why I took this meeting…I do think there’s a huge need for great sushi, and more accessible through your style, price, speed…but I don’t think you’re going about this the right way. 

Shaan/Dan - (zoning out, ready to hear another person talk generically about how 90% of restaurants fail)

John P – Let me ask you this. How much does it take to open a location?

Shaan – About $400k to be safe

John P – And how long is the lease?

Shaan – 10 years..

John P – How long does it take to find a location…6 months? And then to build/design it – another 5-6 months?

Shaan – (nodding, grimly)

John P – So lets say you sign this lease tommorrow. You put in $400,000 to build it, it takes 6 months to open, you’re on the hook for 10 years…and the landlord’s asking for a $100,000 security deposit? And assuming that goes well, it’ll take another year or so to get the 2nd location, and you’ll have to go raise another half a million dollars to pay for it…

Shaan – (nodding, and quickly becoming nauseated)

John – so from the start, commitment is pretty heavy…How many customers do you have on board so far? Have you tested the concept…at all?

Shaan – Well its hard to test the restaurant…without the restaurant!

John – That’s what I thought to myself before you guys came in. I’ve owned restaurants before. And well: everything’s great about owning a restaurant…except the f*%&ing restaurant! So listen to this idea, and tell me what you think…

That’s when he outlined the idea. A radical one. An idea so strange that he left me (someone who talks so much that he’s on pace for an arthiritic jaw by the age of 28) – speechless, with no rebuttal.

If you're someone who thinks about the Lean Innovation approach embodied in the Customer Develpment process and Lean Startup movement you probably know where this is going. Kill the capital investment. Compress the time to market by an order of magnitude. Get feedback and iterate. In otherwords: Kill the restaurant part of your restaurant!

The rest is here where Shaan talks about their new concept. He's funnier and more entertaining than I am so I'll leave it to him to tell the rest of the story of what came out ot the meeting.

I'm excited that these entrepreneurs will open in a few days rather than a year. They'll do it with 1/10th the capital and they will have had 12 months of learning compared to where they would have been following the classic restaurant playbook. I would bet on these guys in almost anything. They have the highest bias for action of any entrepreneurs I've met in the past few years.

I'm proud to have been able to give these guys a little nudge and play a small part in what I'm betting will be their huge success. And, I'm looking forward to helping with the coming operational challenges of starting and scaling.

Sometimes it's good to be the asshole ... just sometimes.

What do we build now? A page from Blueleaf's Lean Startup Playbook (with examples)

Progressive Fidelity Testing at Blueleaf

As a follow up to my last post Letter to a Young entrepreneur I got a number of questions about what to do after building the first version of your product. If you've stripped out everything you could think of, how do you know what to add back?

What should we build next? At Blueleaf, we have a process called progressive fidelity testing to try to answer this and several related questions. Does anyone care? What do they care about? Does our design solve that problem? The idea is to test a feature from concept to implementation beginning with the simplest, lowest effort version that will give us data about user behavior with the feature or concept. We conduct tests right inside the application as well as outside to help us make sure we’re addressing a problem that people care about and that our implementation lives up to our users expectations.

 Does anybody care?

 A simple example of this progressive fidelity testing comes from when we were designing our user reporting. We made some assumptions about what people “needed”.  For example, when looking at their account balances over time, users absolutely needed the to be able to choose different historical time periods: a week, a month, a year. And since those are all rolling time frames, they also must be able to create a custom time frame.

 It turns out that with the type of data we’re working with and the kind of aggressive simplification we’re delivering, custom time frames are time-consuming to build. How important is a custom timeframe to our users? We tested it. We built the selector to include the “Custom” choice.

Picture_21
But when you click on it you get a simple message:

Picture_22

 We turn this click data into votes for the feature. It turns out only 6.5% of users who visit this page voted for custom timeframes. So we’ve held off building it. That saved a couple of days of engineering effort, an additional half day of arguing about including the feature, and gave us a clear signal to make a decision.

 There are lots of folks who’ve written about doing this and just letting the user hit a 404 error. While I think it teaches you the same things, it’s lazy and unnecessarily tells a user that they’re a lab rat. Blueleaf is a financial application, so trust matters, and adding this little “We know you’re a person and appreciate you” message helps users feel good about the site and takes about 30 seconds to implement. Just do it.

 What do they care about?

 In another case, we were trying to understand what kind of financial help our users want and how to make it available in our application. Logging a click just doesn’t tell us all that much. We want to know exactly what they expected, not just that they voted for that feature. Because people may need different kinds of financial help when looking at different types of data, we added a button to every page in the application:

Picture_23

When users clicked on the button, they got this:

Picture_24

 It’s a simple single survey question. With it we’ve learned a few things. 1) People want to know a lot different kinds of things and get information in lots of different ways and 2) Oh yeah, our current users aren’t really that interested in having Blueleaf answering these questions. There are lots of potential reasons for that and we’re digging in qualitatively to understand it better. There is one particularly interesting thing about this feature area. Most people we spoke with or surveyed suggested it would be valuable to them. It was also a very popular suggestion while we were fundraising.  So our customer interviews were diametrically opposed to the behavior of actual users.  The plural of anecdote is not data. Test, test test.

 Does our design solve that problem? (The one they know and care about)

 Outside of the Blueleaf application, we use a number of other tools like Verifyapp.com to help zero in on the right implementation details. In conjunction with typical paper prototyping and show-and-tell style interviews, these kind of tools that can get you a powerful amount of detailed feedback quickly. In particular, we test for what people understand about our design, do they connect it to the problem we verified, does it meet our design goals?

 In one case, we were redesigning a key application page and we were convinced that it had to be graphical. Finance = lots of pretty graphs and charts, right? So we launched a test on Verifyapp. We showed the following screen (It was full size and full detail):

Picture_25

 We asked people what the screen was showing and what they felt when they looked at it. After a few hundred responses it became clear that it failed our core objectives of being simple and understandable. In fact, not one person associated those words or the right problem with this design. That is despite in-person review sessions where people said, “this is great”. It turns out two forces were at work. First: people, particularly when dealing with financial information, have a need to appear that they understand, even when they don’t. No one wants to look dumb. People want to appear to know what they think they’re supposed to know. Interviews create a kind of subtle pressure that makes that behavior more pronounced. Second: people were reacting to some of our unique data on the page, which is admittedly cool, but targeted at solving a different problem. The page design failed.

 Back to the drawing board.

 We ran through that same process two more times and finally removed the cool info from the page, simplified it and dropped the graph entirely. Data on the 3rd round design showed it solved the intended problems and was simple, obvious and easy to understand. Bingo! Cool data isn’t so cool when it makes the page less useful.

 Total time on the iterations on this page, including gathering, collecting, and analyzing feedback from almost 800 people, was under one week and required absolutely No Engineering Time. We implemented the final design in a couple of days and it’s received lots of positive feedback from our current users and importantly, it gets used.           

 Personal finance is a space that is filled with “shoulds” and “must haves”. “You can’t be a real personal finance application without building this or that feature.” Lots of domains and individual visions are polluted with these beliefs. They are BS, a form head trash. That trash creates an incredible pressure to build additional features in the name of progress. It’s not progress. Make real progress and build something that people want.

 

Letter to a young entrepreneur

I just got an email from someone looking for feedback on their product idea. The idea itself was as muddled as most early ideas but what caught my attention was the goals section.

It read:

Goals:

                  1 month- Finalize the concept and find a team

                  6 months: Develop a beta version

                  6 motnhs-1 year: Find companies to run tests with, improve program

It is nearly backwards. The order puts market learning at the tail end of the process. It got me thinking about how much we still need to educate young entrepreneurs. We're making incredible progress in our understanding of how to build a new product/company. But most entrepreneurs understanding hasn't evolved from the "field of dreams" method that has been our history.

Here is my response.

Thanks for sharing. 

I'll focus on the process rather than the idea because you should primarily take feedback on the quality of your entrepreneurial ideas from the market, your target customers.

Goals:Your only goal initially should be to figure out if anyone cares about the idea. Would anyone use it? The largest risk in most tech startups is building something no one wants. If I were you, my process be something like this:

1) Week 1 - Paper prototypes. Draw the basic screens on paper (or in a tool like http://balsamiq.com/) without any polish to flesh out the basic concept and get it out of your head. Words just can't help you think through or communicate the idea nearly as effectively.

2) Weeks 2-4: go speak to people you think have this problem and validate that they have the problem you think they have. If you skip this step early in the process you will waste the vast majority of your time spent on the idea.

a) Ask them generally how they deal with the area of activity you're talking about. See if they raise this on their own as a problem. How are they solving those problems right now and what is missing, sucks or is painful. (Notice I haven't shown them the idea yet.) Job 1 is figure out if they think they have a problem and how it aligns with what you've come up with.

b) Show them the idea and see if they think it could help solve any of the problems they just described.

c) Rinse and repeat with 5-10 peopleThis will be uncomfortable because you'll find that much of your idea is completely off base. But if you're lucky your interviewees will collectively have landed on a part of it that seems useful. 

d) Iterate the paper prototype and story of the idea until you get rid of everything that didn't resonate with your target.e) Go out to a few new people and have the same conversation with your refined prototype and see if you've gotten closer to the mark.

3) Weeks 5-8: Once you've refined the idea to the point where lots of validation from customers that they think this solves an issue for them, start thinking about what it takes to build the smallest, simplest version of the concept which would solve the problem and where a business model (someone somewhere pays you for some value created) might work. Notice the objective still isn't necessarily to build a tech product at this point. It could be you cobbling together a few tools that exist to simulate how you might solve the problem.

4) Weeks 9-10: Put this in front of your the customers you've interviewed and see if they engage with it. Do they care? If not, see what is missing in both your understanding of the problem and the way you've solved it. Customers cannot tell you how to solve the problem. They can only tell you that they have it and that your thing does or doesn't work for them. Don't expect more, you'll wind up misguided.

Think about the process as being focused on testing your ideas in the real world as quickly and cheaply as possible. Speed in this case needs to be how fast can you go through this cycle of learning from customers and incorporating that into a "product" which starts out as paper and gets progressively more real as you have more data and validation.

The only thing you might need if you really struggle drawing the screens is someone to help with that, a web designer, who you could also audition as a co-founder by working through this process.

I think what you'll find is that the problem that you think you've identified is adequately solved by some combination of other things but a subset (more likely) or super set (less likely) of that problem isn't and that will be what you can run with.

The advantage to this approach is twofold. 1) It lowers the likelihood of solving a problem no one cares about and 2) Assuming you find a problem that's worth dealing with, you'll have more real world data and a deeper understanding of that problem than many other who might work on it. That makes it more likely that you'll be able to attract the people and money you'll need to move forward.

There are lots of books and blogs written about this approach. Take a look at the following for a deeper dive.

www.steveblank.com

www.startuplessonslearned.com

http://market-by-numbers.com/

http://www.custdev.com/

http://www.ashmaurya.com/