{"id":1799,"date":"2020-12-16T07:00:10","date_gmt":"2020-12-16T07:00:10","guid":{"rendered":"https:\/\/thenextweb.com\/?p=1331532"},"modified":"2020-12-16T07:00:10","modified_gmt":"2020-12-16T07:00:10","slug":"5-startup-scaling-mistakes-and-how-to-avoid-them","status":"publish","type":"post","link":"https:\/\/www.londonchiropracter.com\/?p=1799","title":{"rendered":"5 startup scaling mistakes and how to avoid them"},"content":{"rendered":"\n
<\/div>\n

A couple of years ago, I was at a holiday party. One of the hosts told me about another guest at that party who was starting a company and mentioned that I should talk to him.<\/span><\/p>\n

I love startups. I love anyone willing to go on that journey. So from the gate, I already want to do anything I can to help him out. When I eventually ran into him, we started chatting.<\/span><\/p>\n

He started pitching me his idea, and he spoke for 30, maybe 45, minutes. Finally he paused to take his first breath. I told him I thought his business idea was really cool, which it is. Then I asked him, \u201cHow many users do you have?\u201d<\/span><\/p>\n

\u201cOh, we\u2019re still working on the business plan,\u201d he told me.<\/span><\/p>\n

\u201cAll right, how long have you been working on the business plan?\u201d<\/span><\/p>\n

\u201cAbout 18 months.\u201d<\/span><\/p>\n

\u201cDo you have any software developers?\u201d<\/span><\/p>\n

\u201cYeah, my friend studied CS and we\u2019re working on this together.\u201d<\/span><\/p>\n

\u201cWhat\u2019s he doing?\u201d<\/span><\/p>\n

\u201cHe\u2019s working on the business plan with me.\u201d<\/span><\/p>\n

I ended up talking to my fellow party guest for over 2 hours. I told him everything I\u2019d learned working in software startups for the last 20+ years. My conversation with this startup founder made it clear to me that while startups are glorified throughout the business world, very little is understood about the day-to-day experience of being inside one, and especially what good technical leadership looks like from the driver\u2019s seat. <\/span><\/p>\n

Startups are a wild ride, but they also put a lot of pressure on their leaders to make the right choices, find signals from noise, and move fast. It\u2019s a stressful position to be in. Every decision feels crucial. But there are a few key strategies that will help you focus on what matters, and not waste runway on what doesn\u2019t.<\/span><\/p>\n

1. Be hungry for feedback, and be ready to change radically, quickly.<\/b><\/h2>\n

The most important thing I can tell you about how to succeed in a startup boils down to this: be hungry for feedback and be ready to change radically, quickly. <\/span><\/p>\n

How can you do that? <\/span>Lower what it costs you to make a change.<\/span><\/i> The lower the cost, the more able you will be to seize opportunities, and the less likely you\u2019ll get tied down by your previous bad decisions. <\/span><\/p>\n

Cost of change is one of the most important ideas that you can grapple with as a technology leader. The drivers of that change will evolve with the growth of your business, but in the early days when you\u2019re trying to figure out product-market fit, the scope of change is massive.<\/span><\/p>\n

A podcasting system called Odeo ultimately became Twitter, a giant social network. Tiny Speck, a gaming engine, becoming Slack, a wildly popular messaging platform. These represent sweeping fundamental changes to business models. Making small and large changes is what enables ultimately finding product-market fit.<\/span><\/p>\n

2. Find your product-market fit <\/b><\/h2>\n

Getting feedback from customers is the most important thing you can be doing at the nascent stage of any business. Modern software tools make it possible to get your ideas in front of users on day 1 of your business, and that wasn\u2019t always the case.<\/span><\/p>\n

I had my first job in software in 1998. Things were pretty different then. Our first server lived under my desk. When we raised a seed round, I flew to Herndon, Virginia to build out our data center myself. I flew in a plane with a suitcase full of disk drives. That was how you got software onto the internet in 1998. <\/span><\/p>\n

Today, you are lucky enough to be building a business in the age of AWS, Heroku, and serverless \u2014 which means you have an advantage that I didn\u2019t have in 1998; in fact it didn\u2019t exist for 99.99% of business history. <\/span><\/p>\n

Modern cloud deployment platforms give you the ability to get your ideas in the hands of users faster than ever before. With tools like this, you can focus entirely on building your product as users are interacting with it, so you can learn from those users as quickly as possible.<\/span><\/p>\n

3. Don\u2019t do \u201cstealth mode\u201d<\/b><\/h2>\n

Stealth mode is the period in which startups build their product in secret, and won\u2019t talk about it or show it to anyone for fear someone else will steal their idea.<\/span><\/p>\n

Before I explain why this is a bad idea, let me first say that the fear around which stealth mode is constructed is generally unfounded. People are not sitting around, just waiting for a great idea they can steal and then build. If someone had the time and the energy to steal your idea, they probably already have their own idea, and they\u2019re working on that.<\/span><\/p>\n

But more importantly, for anything that you\u2019re currently working on, there are at least three other teams somewhere, right now, also working on that idea. <\/span><\/p>\n

The best thing you can do isn\u2019t to work on it in secret, but to build it, and get it in front of customers as fast as possible. <\/span><\/p>\n

4. Don\u2019t write a business plan, build an MVP<\/b><\/h2>\n

Before you say \u201cRob Zuber told me not to have a plan,\u201d I think it\u2019s great and important to have a plan \u2014 just be able to articulate the plan in a single sentence. Don\u2019t plan further ahead than you have to, which means: plan your next step, build it, and get feedback. Then amend the plan. Repeat.<\/span><\/p>\n

The absence of that large-scale, upfront, 3-ring-binder type planning is often interpreted as a lack of a plan. But really it means that I\u2019m planning to be in an optimal position to seize an opportunity and that I will evolve the actual plan along the way as I do the work.<\/span><\/p>\n

The real reason to not write a business plan is that no matter how smart your business plan is, you\u2019re wrong. You\u2019re wrong about <\/span>something<\/span><\/i> in your business. Think back to those three other teams building your same idea. They\u2019re wrong, too. But none of you understand what you\u2019re wrong about yet. Your only strategy at this point is to be wrong as fast as humanly possible (ideally faster than those other teams) so that you can find out what right is and start building the right thing.<\/span><\/p>\n

This probably won\u2019t surprise you, but this advice isn\u2019t only for early-stage startups. At every stage, keep up this cycle of building, executing, and getting feedback. It\u2019s only in this feedback cycle that you\u2019ll learn where you\u2019re wrong and start to get more right.  <\/span><\/p>\n

Building the world\u2019s most impressive business plan is not finding product-market fit.<\/span><\/p>\n

So put down your business plan. Find the simplest possible approximation of your idea that will give you any kind of signal. Build that in an afternoon and then go give it to someone and see if they care. Do whatever it takes to find that out \u2014 it shouldn\u2019t take 18 months and a 90-page document. <\/span><\/p>\n

5. Depend on uncertainty<\/b><\/h2>\n

At any point, something crucial about your business could change. But you don\u2019t know what or where yet. <\/span><\/p>\n

In \u201c<\/span>97 Things Every Software Architect Should Know<\/span><\/a>\u201d Kevlin Henney describes an important approach to <\/span>thinking about uncertainty<\/span><\/a>:<\/span><\/p>\n

\n

The presence of two options is an indicator that you need to consider uncertainty in the design. Use the uncertainty as a driver to determine where you can defer commitment to details and where you can partition and abstract to reduce the significance of design decisions. If you hardwire the first thing that comes to mind, you\u2019re more likely to be stuck with it \u2013 incidental decisions become significant and the softness of the software hardens.<\/span><\/i><\/p>\n<\/blockquote>\n

This framing is great for explicit decisions, but what if you don\u2019t know you\u2019re making a choice?<\/span><\/p>\n

Many times, the choice isn\u2019t even visible yet but will reveal itself later. In these situations, the answer is not to overgeneralize, building abstractions everywhere \u201cjust in case.\u201d <\/span><\/p>\n

Implement abstractions in only the places you have identified that have multiple implementations, i.e. items with a high cost of change, where you also have high confidence that there will <\/span>be <\/span><\/i>a change. <\/span><\/p>\n

Building perfect abstractions all over the place will certainly protect you against inevitable change, but will also be impractically costly. Instead, keep things as simple as possible so you can understand them later if you have to make a change. By merely separating concerns and keeping like with like, you still have work to do when it comes to making changes, but the cost of doing the work is low.<\/span><\/p>\n

Build in a way that minimizes the cost of being wrong, and then watch change closely.<\/span><\/p>\n

Published December 16, 2020 \u2014 07:00 UTC <\/p>\n

Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

A couple of years ago, I was at a holiday party. One of the hosts told me about another guest at that party who was starting a company and mentioned that I…<\/p>\n","protected":false},"author":1,"featured_media":1800,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/posts\/1799"}],"collection":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1799"}],"version-history":[{"count":0,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/posts\/1799\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/media\/1800"}],"wp:attachment":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1799"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1799"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1799"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}