You see plenty of articles from successful entrepreneurs claiming all sorts of reasons for their success. I remember one such article claiming that having a CEO in Chicago and a CTO in the Nordics was a major part of their success #survivorbias
Successful founders often fool themselves on the reasons for their success. It's because we followed this process or methodology. It's because we adopted this pricing or go to market strategy. Often it's hard to tell whether something was because of or despite these things.
As such it's refreshing to see an open and honest reflection on why a startup failed (which most do). As an industry we talk a good talk about failing fast and failing often. However it's actually quite rare to see people dissect this stuff in public. So kudos @JamesDLamming
• • •
Missing some Tweet in this thread? You can try to
force a refresh
The world is full of middle managers who are sufficiently far away from doing things that they forget how hard it is, but have an eye for detail and will happily pick you up on the smallest thing.
This is usually because when you’re doing a project you’re confronted with dozens of issue that need addressing, and will generally work through them in a systematic manner. With so many problems to tackle it’s easy to miss or deprioritise a few.
However when your manager sees the output they’re not seeing all the things you fixed. Instead you’ve cleared away the weeds making it much easier for them to notice all the inconsistencies.
Product Managers have taken a huge chunk out of the design teams agency by framing insight gathering as “product discovery”.
Product managers have taken research up stream and framed it as a value add to product development. They talk to users, understand their pain points, come up with potential solutions and then had these to design and engineering to implement.
Design then goes “where did this idea come from? We need to do the research” by which times it’s arguably too late.
It’s an age old debate (in a tiny section of the UK at least). Should you put the jam or cream on your scone first? The answer generally comes down to whether you spent more time in Cornwall or Devon as a child. However both sides of the argument are wrong. Here’s why 1/n
The true answer has nothing to do with geography and everything to do with viscosity. Do you have a very viscus (ie cold, probably clotted cream) and a very loose jam? In this case you need to spread the cream and then dollop the jam 2/n
If however you have a highly viscous jam, and a less viscous creams, you clearly need to spread the jam and then dollop the cream on top. As such this argument is based largely on the produce you have (and slightly less so on the temperature of said ingredients) 3/n
In most tech focussed companies, the size of the engineering team will massively outweigh research, design and product management.
These teams are under a huge pressure to deliver so CTO are focussed on creating the conditions for this to happen.
Books like Accelerate and Team Topologies have encouraged technical leaders to set up their teams and culture around managing engineer efficiency. Anything that gets in the way is an obvious distraction.
This includes the idea of minimising team cognitive load. Anything that adds unnecessary cognitive load to a team is deemed understandable and ideally removed. Individual teams might be agile, but as a discipline it can feel like a bit of a freight train.
Designers often misunderstand the level of domain experience founders and exec teams have. They might not be doing what we’d consider “good research”, but they’ve often been talking to customers and bathing in the problem space for a considerable time.
Because of this a lot of founders and executives have surprisingly good instincts which is where a lot of their product ideas come from. This doesn’t feel “right” to many designers so we tend to push back and advocate for “proper research”.
I should add that a lot of the solutions founders and executives come up with are “the obvious solutions” but as designers we know these might not be the “optimal solutions” which is why we press for more research and testing.
You can learn a lot through rapid iteration if you believe failures are survivable.
However if you don’t believe failures are survivable, or you believe you only have a limited number of chances, people are much less likely to take the risk.
For instance if you have a large amount of money you’re likely to take more risks. If you’re running out of money and need to show traction to raise the next round, you’re likely to be more conservative.
If you’re using somebody else’s money (and don’t need to pay it back), you’re likely to take more risks. If your using your own money (or money you’ve earns through boot strapping) the risk feels much higher.