How To Run A Startup Before You Start One

https://www.slideshare.net/qzuryu/ss-44468259

＊＊＊

The following are 7 items summarizing, from my experience moving back and forth between “big companies” and “startups,” the ideal organizational structure and mindset for driving a “startup” or “new project.”

There are naturally a mountain of industries and other exceptional cases where the premises defined here don’t apply, but I’m ignoring those here

① Flexibility

Be understanding toward pivots – The more legitimate pivots there are, the better – But don’t do a “table-flip” (details below) Keep the human resource base small and agile – Build a team made up entirely of people who can broadly handle many different things rather than specialists (ideally, every single member has enough individual development capability to bring a product to completion even if they were the only one left) Don’t fix the platform – Not just from a technical standpoint, such as key components like OS, processor, sensors, and so on — keep your outsourcing partners and the carriers you work with unfixed as well, for as long as possible

② Emphasize speed

Run through many trial-and-errors and push toward resolution – In other words, “just try it for now” Build an experimental PCB and write test code before writing a spec document – The spec document is for communicating with external companies, not for getting internal approval – It’s fine to have the internal discussion after the experimental prototype already works Don’t spend time and money on things whose effect is hard to measure – Website maintenance, advertising, trade show exhibits with unclear intent, and the like – If you have time to spend on that, write one more line of code, run one more proof-of-concept experiment, and have one more conversation with a user, a prospective user, or a component manufacturer

③ Emphasize efficiency

Don’t hold meetings other than discussions and brainstorms – Reporting and sharing should happen within ordinary conversation, in person or digital – Don’t grow the team beyond the size that makes this possible Throw out the concept of a normal work schedule – A good engineer, if bound, will work exactly 240 days a year (the number of working days for civil servants); unbound, that same engineer will work 365 – Office hours, overtime, working on days off, paid leave: treat all of these as nonexistent – Think in terms of the project, not the hour – Allow remote work and WFH. If that means people stop gathering at the office, the project is already dead (if anything, that’s a good barometer) Introducing efficiency-improvement systems for operations almost always makes things less efficient – The simple answer is to just use the tools everyone already uses normally – Google Apps, Evernote, Dropbox, Facebook, and so on

④ Centralization of information

Limit reporting routes as much as possible. Ideally, one person is the point everyone reports to – Dispersed information becomes a factor that trips you up at critical moments – This should be achievable at least while the organization is 10-20 people – Being that reporting target is a pretty tough job, but an extremely important one, and whoever holds it should carry it out with that awareness Trying to manage things through regularly submitted documents and the like is the manager cutting corners, and it actually makes overall efficiency worse

⑤ Don’t do table-flip pivots

Pivots are necessary. Important, even. But a “table-flip” — resetting everything — amounts to condoning a waste of time and money – You’re free to do it, but that’s the moment you dissolve the department and the person in charge takes responsibility. What comes after might go well, but by then it’s already a different company, a different project – That said, “somehow squeezing out something that looks like a reasonable pivot” is also the wrong stance. If you’re only thinking about it once you’ve reached that point, it’s too late Take the flexibility from ① seriously, so that healthy pivots stay possible – Act while always keeping several options clearly laid out – Tunnel vision is inevitable once a project gets moving. So it’s right to worry about this more than feels necessary

⑥ Chemical reaction

Gather people with as many different roots and career backgrounds as possible for the team – Synergy is born just from people in different industries talking to each other (that’s how a certain startup grew) Once the team is formed, put effort into cultivating chemical reactions within it – Networking events get people excited, which makes it tempting to keep doing them, but what matters most is what happens internally Freedom of tool choice – Let each member choose tools according to their own preference. The extensibility that emerges from that becomes an asset of the organization

⑦ Think deeply, but don’t build deeply

Specs need to be thought through deeply. A major overhaul of specs after release is almost always a sign of defeat But don’t build things out too deeply. That’s the domain of companies with a “brand,” and it doesn’t suit startups – This is only permissible in “a market with timeless staying power” or “a situation with no rivals present.” But there’s no example of a startup succeeding in that kind of market – Thinking is free. Building things out costs both money and time There are countless examples of products that sank despite a lot of time spent building them out, only for the finished quality to be mediocre And there are just as many examples of something that, at launch, made people go “wait, what is this, lol,” gradually gaining acceptance and eventually rising to become the de facto standard

Originally published in Japanese at https://clazytech.com/2015/02/334/. Translated with LLM assistance and reviewed before publication.