Get It Done, Then Get it Right
Get it done, then get it right. I find myself saying that a lot in the last week. Our startups are now two weeks into the program, and they’re getting a lot of advice. They’re getting so much advice, that it’s forcing them to rethink important assumptions they’ve been making about their market, their business, and their products.
They’re learning to question everything they took for granted before. And yet, this is also a time in which they have to execute faster than they ever have. Constant mentor meetings where your basic understanding of things is being questioned, is very hard to reconcile with the urgency to get it done, and get them out into the world.
Get it Done
One very dangerous trap for startups in this stage, and one that is a fact of life particularly in an accelerator, is that of “over-mentoring.” Last week, after one meeting, Executive In Residence Viktor Fischer put it to me this way: “Startup founders have to be good listeners. But sometimes they can even listen too much. Then, before you realize what’s happening, they’re interviewing the mentors about what they need to do next, instead of making decisions and dealing with the consequences. They’ve been over-mentored.”
This cuts right to the heart of the problem, I think. Startups can get caught in a cycle of analysis in which they devise ever more elaborate and subtle plans. The plans they are making get more and more fantastical, and yet not a line of code gets written, and not a single customer gets approached.
I’ve seen startups with ridiculously elaborate onboarding charts and picture-perfect mockups of web pages that exist only in those forms. And in a way, these startups are setting themselves up for very big disappointments, when they inevitably find out that the designs and charts they’ve spent so much time on don’t work when finally, laboriously implemented. Will these founders then go back to the drawing board, throw out all that code, and completely rewrite the plan?
That can become the only way a startup knows how to work, and it turns small problems, like the placement of a button on a landing page, or the exact order and number of items in an onboarding process, into huge, crushing burdens.
Quick and Dirty
Reid Hoffman (founder of Linkedin) has famously referred to getting things done as a startup this way: “you jump off a cliff, and you assemble an airplane on the way down.”
For a long time, that sounded to me like so much tech-industry jargon. People often said it, but it was just too macho for me. Too much brag.
But in the past few years, I’ve come to appreciate the sentiment in an entirely new way, as I have watched startups essentially re-invent the concept of flight, test multiple designs with elaborate models, and then, just before they’re almost completely out of money, more or less tumbled over the cliff without the materials necessary to build the aforementioned plane at all.
The old adage “you only get one chance at a good first impression,” is something a lot of our startup founders take too closely to heart. I’ve realized that more importantly, a startup has to worry about having any chance to make any impression at all, much less a good one.
So I’ve taken to pushing our startups to be, as I call it: “quick and dirty.” When one startup was struggling with a new pricing strategy and pricing pages, I asked them how long it would take them to make a pricing page that looked decent, and worked as expected.
“Well,” the answer came, “we have to make some changes in the product to support the new pricing, and then design the page, and then we can release it in a few weeks.”
I wasn’t having it. “How can you do this in the quickest, dirtiest way possible?”
They weren’t sure what I was talking about.
“I’m saying, build the page, then connect it to your existing product, and then fix the product so that the new pricing works properly with the new types of users.”
“That will be really messy, and there will be some bugs.”
“And you can fix those bugs?”
“Yeah, we guess so.”
“Good, so get this done by Monday, and we will release it, bugs and all”
The founders walked away in slight shock. Their 2 week development process had been cut to 3 days, and they were not going to be able to completely connect the new pricing with the product itself, so the product wouldn’t work exactly as expected when new customers activated trials. The product would not be perfect.
But the next day, they came to me with a new pricing page done. It looked decent. And when you clicked on the prices, it would lead to a trial signup. The founders would then manually connect each account to the account functionalities that had been requested on the pricing page. It was ugly as a solution, but it did work, and now they were able to immediately see whether the new pricing was going to attract customers or not.
If they had to take time out of their day to manually add more users, and it became a big problem, it would at least be a good problem. And they’d have a very good, very revenue oriented reason to solve it.
The two weeks were a fantasy- but now they were dealing with something that needed their attention in order to work. That made them work harder, and more efficiently, and they had it working in far less time than they had anticipated.
Interesting in Theory
Part and parcel of this problem is that startups can stay too long in the realm of theories and ideas, and keep their mentoring sessions on the surface, rather than having mentors react critically to real work that has been done.
I love to discuss ideas with startups, but there is only so much I can do by imparting my philosophy and my instincts about what they should do next. If a startup asks me how to plan an email campaign or a landing page, I may have a lot to say. But that won’t be 10% of the value the startup would get if they just created that campaign, or built that landing page, and then came to me for a reaction.
With something real, I can point out mistakes, and push them in the right direction, telling them as much what not to do, as what to do. If it’s just a plan, I have know way of knowing whether they have good instincts or not. I don’t know if the even can get it done. I don’t know how capable they are, so I can’t calibrate my advice to best help them as individuals.
Jumping Off the Cliff
This is really what jumping off the cliff means. Engineers naturally seek order. They try to anticipate problems in order to solve them before they arise. But you need to have some problems in order to motivate yourself to be productive. You also need to be in contact with your users in order to understand what they want.
The internet today isn’t the same as big industry a century ago. Companies don’t have one shot at getting things exactly right. They now have to create that shot, and correct their errors and fire again as fast as they can.
A hundred years ago, if Ford built and sold 10,000 cars, they all had to pretty much work right away. The web has changed that, but engineers haven’t totally recovered from that 20th century mentality. Still, it’s essential that startups break out of “planning mode,” and put themselves in uncomfortable and dangerous territory. It’s the only way they can distinguish themselves between the planners, and get it done.
