Seven Rules For Launching A New Project

This is a slide deck I made a while back — a friend told me to reread it, and it turned out to say some surprisingly good things, so I’m copying it over here. https://www.slideshare.net/qzuryu/ss-44468259

What follows are seven points summarizing what I’ve learned, from moving back and forth between “big companies” and “startups,” about the ideal organizational structure and mindset for driving a “startup” or a “new project.”

There are obviously plenty of industries and exceptional cases where these premises don’t apply, but I’m ignoring those here

① Flexibility

Understanding toward pivots

• The more legitimate pivots there are, the better
• However, don’t do a “table flip” (details below) A small, agile pool of human resources
• A team made up only of people who broadly handle many things rather than specialists (ideally, everyone on the team has enough individual development ability to ship a product even if they ended up alone) Don’t fix the platform
• Not just from a technical standpoint — key components like the OS, processor, sensors, and so on — but also outsourcing partners, the carriers you work with, and so on — run the project keeping as few things fixed as possible

② Prioritize speed

Push toward a solution through many trials and errors

• 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 outside companies, not for getting internal approval
• It’s fine to have that discussion after the experimental prototype is up and running Don’t spend time and money on things whose effect is hard to measure
• Website maintenance, advertising, exhibiting at trade shows without clear intent, and so on
• If you have time to spend on that, write one more line of code, run one more validation experiment, and talk to one more user, prospective user, or component manufacturer

③ Prioritize efficiency

No meetings other than discussions and brainstorms

• Reporting and sharing should happen through ordinary conversation (in person or digital, doesn’t matter)
• Don’t grow the team to a size where that’s impossible Throw out the concept of a normal work schedule
• A good engineer, if constrained, will work exactly 240 days a year (the number of working days for a civil servant), but left unconstrained, will work 365
• Office hours, overtime, working on days off, paid leave — treat all of it as nonexistent
• Stay conscious that you’re working project-based, not hourly
• Allow remote work and WFH (work from home). If that means people stop gathering at the office, the project is already dead anyway — that’s actually a good barometer Introducing operational efficiency systems almost always makes things less efficient
• The simple answer is to just use the tools everyone already uses day to day
• Google Apps, Evernote, Dropbox, Facebook, and so on

④ Centralizing information

Limit reporting channels as much as possible. Ideally, designate one person that everyone must report to

• Fragmented information becomes the thing that trips you up at critical moments
• This should be achievable at least while the organization is 10-20 people
• The person who is that reporting target has a genuinely hard job, but it’s extremely important, so they should do it with that awareness Trying to manage things through periodically submitted documents is the manager cutting corners, and overall it makes things less efficient

⑤ Don’t do table-flip pivots

Pivots are necessary. In fact they’re important. But a “table flip” — a total reset — amounts to endorsing wasted time and money

• Of course it’s fine to do that, but that’s the moment when you dissolve the division and the person in charge takes responsibility — and even if things go well after that, it’s effectively a different company, a different project
• That said, the attitude of “somehow scrape together a pivot that seems reasonable” is also wrong. If you’re only thinking about it at that point, it’s already too late Take the flexibility mentioned in ① seriously, so that a healthy pivot is possible
• Always act with several options clearly laid out
• Tunnel vision obviously sets in once a project gets moving, so it’s just right to be a bit overly cautious about it

⑥ Chemical reactions

Gather people with as different roots and careers as possible for the team

• Just having people from different industries talk to each other generates synergy (that’s how a certain startup grew) Once the team is formed, put effort into fostering chemical reactions within the team
• Networking events do get people excited, so it’s tempting to just do those, but what matters first and foremost is the inside Freedom in tool choice
• Let each member choose tools according to their own individual preferences. The growth that emerges from that ends up becoming an asset of the organization

⑦ Think deeply, but don’t build deeply

You need to think deeply about the spec. A major overhaul of the spec after release almost always means you’ve lost But you shouldn’t build things out in depth. That’s the domain of things that have a “brand,” and it doesn’t suit a startup

• It’s only permissible in “markets with vast timescales” or “situations with no rivals.” But there’s no example of a startup succeeding in that kind of market
• Thinking is free. Building things out in depth costs both money and time There are countless cases of projects that spent a lot of time building things out in depth, only to fall flat because the finished quality was mediocre On the other hand, there are also countless cases of things that at launch drew reactions like “wait, what is this, lol,” but gradually gained acceptance and eventually rose 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.