Move fast, but understand the problem first
jacobobryant.com
jacobobryant.com
I think the correct fundamental framework, which is compatible with all sides of the argument, is that you must be mindful of your learning rate. Some approaches are depth first - perhaps that depth is satisfactory to learn what you need to solve real problems. But perhaps what you actually need is breadth. There is no way to say which is right - you literally have to just stress it out, it's not fun. Some problems only yield information when you have skin in the game - there's no way to reason out the right approach, you need to push at real boundaries and see what happens. Some of the boundaries, all of the boundaries, keep pushing, take a pause... again, you can't know for sure what's right. All you can do is constantly ask yourself - am I learning? Am I generating hypotheses, testing them, proving at least some? The framework is different for everyone, and it's _work_.
When your mind is going hither and thither, discrimination will never be brought to a conclusion. With an intense, fresh and undelaying spirit, one will make his judgments within the space of seven breaths. It is a matter of being determined and having the spirit to break right through to the other side.”
- From the Hagakure
So much wasted effort results... but, hey, at least I got paid for it. And now I make sure I don't work anywhere where they run this playbook anymore!
They act fast and self assured to assert dominance. The one who speaks loudest first wins.
This behavior can be observed in chimps too, often the most dominant male performs the most amazingly loud and aggressive acts.
In environments that are more collaborative and less hierarchical it’s different. Ideas, not humans are competing and different approaches merge.
I don’t want to bash on chimps here. That would be unfair.
also ... the author cites sam altman as evidence that his thinking is on the right track, but can you really argue against a statement like "Almost everyone I’ve ever met would be well-served by spending more time thinking about what to focus on"? that's about as close to a one size fits all statement as "almost everyone who succeeds thinks"
i sometimes wonder if this comes from a place of fear. Maybe we're scared of really listening to customers / users / colleagues / stakeholders and so we invent these rules to hold ourselves accountable for what's probably pretty obvious from the outside
It truly is just not in our nature.
We are also always trying to navigate the world constantly, and talking is a way to test our world view against other people. This is why we talk.
So; Talking (articulating the world view) and hopefully getting a affirming response to that is less expensive to our system than throwing away that paradigm and learning a new one.
to circle back to the original topic of understanding the problem, a big part of that is being observant and attentive to the needs of users. In that context and using your framing of this in terms of cost and resistance, I agree that simply talking and stating opinions is far easier than shutting up, talking to users, and gathering real information about what they actually want
Anyway, discussing the wisdom rally cries, 15 years later... Most business wisdom is temporal. What applies to a >10 person startup hoping to raise $4m by the end of 2006 may not be the applicable wisdom today.
I read this post as saying that, given how product development is path-dependent, most people should do a lot more up-front discovery work than they are today.
What I mean is, it's empirically very rare for people to just throw away a bad idea: they're more likely to modify it, pile more features on to it, or just delude themselves into thinking it will work eventually. But, usually it doesn't.
We can say "be willing to throw it all away and start over when you learn new information", but in practice people don't do this. So, it might be more effective for most people to do, say, 50% more up-front work than they're already doing to de-risk their ideas before committing anything to them. It's clearly not a guarantee of success, just a way to improve your chances and save your own time.
I've heard this called the Feynman technique before. Pretend as if you know what you are doing and what to do, than start doing it as if you knew how, and each time you fail or realize you don't know how to proceed, stop, go learn only as much as you need too unblock your next step, rinse and repeat.
It's a really good way to eventually learn and succeed, while wasting as little time as possible.
The issue is that, when it comes to software development, where you need to build upon what you've done before to keep moving forward, the risk is that all your prior steps weren't considering your next ones, and at the time you built them you didn't really look further, you were focused on figuring out only the next move pretending you knew it all.
So in a startup setting, it kind of means that if you follow this technique, you'll quickly learn and figure out what and how to do things, but you'll also fail a lot, and those failures will pile up, and all you built during that process might not end up being usable in the end, as it could be a monster of tech dept, limitations and bad decisions.
That's where a lot of startup have a "big rewrite" phase normally.
This still works if you are okay with having that big rewrite/refactor phase, and as long as your monster was still good enough to carve you a big customer base or investor interest, that'll be patient enough to wait for your rewrite.
I'm not sure how to summarize this, but there are some problems that each step you take you've now advanced closer to the solution, so it's fine to not think holistically about it all, but focus one thing at a time. While there are other problems where that only take you so far, and at some point you have to think holistically, do I need to do anything about this foundation in planning of what I'll later build upon it? That kind of thing.
But I think often what happens is people are too afraid to fail, and they start thinking holistically, except they actually are not expert enough to be doing so. So they start thinking all hypothetical, imagining the problems that will come, and that all ends up a waste of time.
If they'd tried, tried and tried some more, then they'd actually have learned a lot, and now would possibly be on a place to actually think holistically.
I heard a pretty good saying on that:
"The difference between the master and the beginner, is that the master has failed more time than the beginner has tried".
I think it's by Stephen McCranie
But that's just what thom's talking about. Sometimes you need to know when to quit.
I'm not normally one to link to Dilbert, but: https://dilbert.com/strip/2012-11-20
There's this idea of "problem holder" that Walt Beleyer at Sandia National Laboratory talks about. Holding the problem and deeply understanding is sometimes neglected in the rush and joy of building. Fwiw, I wrote a post about that here:
You win the startup game by being in the right place at the right time. The longer your survive, the higher your odds of being "at the right time".
Most "overnight successes" were 10+ years in the making.
I've observed this most pathologically at organizations running the "hyper growth" playbook.
I don't think that's clear at all. Many "loved" sayings are "loved" because they help spur one into behaviours one otherwise would not partake. If you think about it, sayings about predisposed behaviour can often seem unremarkable. It's like corporate values: the published corporate values are ultimately as much aspirational as actual, because the purely "actual" values are assumed. (For the same reason, if you ask someone what is most important to them, no one says "breathing" or "air".)
> But they move so fast they haven't had a chance to understand the saying!
Iterating on NOOP can be done a lot faster, and at much less expense, than iterating on something; I'd like to think the eventual steady state of such folks will be to do absolutely nothing very, very quickly. ;-)
Hey, human reasoning can take you to some dark places, so I don't begrudge people where they end up. I'm just confused by how... broad? the phenomenon is. I'd expect some kind of Darwinian forces/selection bias that would eventually relegate such thinking to a quite corner of the universe.
The counter to this are stories like Stripe. Collison has famously said they never would have started the company if they actually knew how hard the problem was when the started. They identified the problem and committed to solving it. But jumping in blind increased their chance of actually making something unique instead of just another credit card gateway.
Yes, but the "work on it" should be designed so that you progress in that understanding. Too often it does not.
I went in thinking “oh I’ll just pay some people to fix all the technical things and I’ll do what I’m good at: sales.”
Money ran out and so far I coded a website from scratch, learned web design, written software for the unit and just finished the first circuit boards. And the further I get the deeper the rabbit hole goes. It’s probably gonna take 20 years to get where I wanted to be in 5 and that’s fine.
It seems like some people are commenting that the advice in the article is common sense, but I think when your mindset is to move fast, it can be easy to delude yourself into thinking you understand a problem when you're really just married to an idea but too scared to go out and discover whether it's actually solving something real or not.
My team and I, 4 engineers, we focused for about 2 years only on moving fast, and moving on doing a feature battle with the competitors.
After all this this we stopped and restarted a new journey focusing on things that really matter: - Why - How - What Are we doing it, and it changed everything for us.
My teammate has posted the story of the last 7 years of my team today, i give you the link if you are interested in knowing more:
https://medium.com/leapp-cloud/road-to-noovolari-89df7704e31...
I have a notebook with all corners we cut at my current project. Also a bunch of other stuff (like various types of problems). The new designs are getting evaluated against my notebook.
I know it sounds funny but I just can't get into agreement with other people on how to make notes of technical debt and so, not wanting to spend too much effort on it, I just made it a notebook which I am diligently filling whenever I hear something that I would like fixed.
Sometimes "measure twice cut once" makes sense, sometimes it doesn't.
My standard is that by the time you finish, you should understand the problem as well as how your solution works.
Furious activity is no substitute for understanding. - H. H. Williams
This is usually a critique of younger star athletes where they only have one gear when they first come into a league (usually that gear is just pedal to the metal). It takes a little bit of time to understand how to adjust pace so as to be able to move quickly in some phases, and slowly in others.
The trick is to keep moving (doing).
For the tech parts I recommend the word "deliberate" with the motto "make haste slowly"
Who'da thought it that to get stuff done quickly but correctly, ya gotta move fast, actually do things, but also think about what you're doing. Mind = b l o w n!
As much as this seems self-evident, I think it's worth saying it explicitly, because I do think a lot of people skip the thinking and sometimes even the doing, and end up just moving helplessly in urgent nonsense that takes you nowhere, doing nothing more than panicking.
Only though experience do we know what is and is not worth our time (and thinking)