Recent learnings in my startup and a great book titled How to Be Miserable: 40 Strategies You Already Use have sparked my inspiration to write a BAD ADVICE guide on how to mess up Product, Design and Engineering.
If you disapprove of self-help books, this tongue-in-cheek, refreshing guide might be just what you need in a global pandemic.
1) We do 1x thinking, 10x building.
“We need to move fast and try a lot of things”. Use this famous mantra to make your Design and Engineering teams happy to build lots of things that validate nothing. You’ll also gobble up those vast resources of time, money and people that startups have in abundance.
2) We seek design by consensus.
Make all important decisions by committee. Don’t split ownership and responsibilities. Even better, pit teams against each other to come up with their best ideas then wait until there’s consensus between everyone… even customers!
3) We don’t have a strategy — we’re Agile.
When faced with an overly negative or positive voice from a customer, an investor or a team member, react quickly by changing resolutions without considering the overall strategic plan. It’s more important to move fast than to move in a particular direction.
4) We don’t waste time documenting — we’re Agile.
It’s too much effort to keep sharing and updating information about what has changed and why. Take everyone on a merry-go-round by skipping to document critical decision-making in writing. Nobody has time for PRDs, RFCs and ADRs.
5) We have many hair-on-fire priorities.
Select a healthy chunk of top priorities and ship many features every day. Ensure that Design and Engineering get plenty of change requests via multiple communication channels. Context switching is good, it keeps people on their toes, alert and multi-tasking.
6) We collect lots of data. No, we don’t know what it means.
Deprioritise data collection and analysis until you’re successful enough. It’ll help you cut costs and time-to-market. When you finally have some data, use it infrequently and look at the hard numbers. It’s the math that counts. And if the numbers don’t match, simply ask the team to collect more data.
7) We launch with must-haves only.
Prioritise making the product work first and look pretty later. If customers have enough buttons, they’ll figure out what to do with them. When designing or coding, work in isolation and make fast progress by skipping those time-consuming conversations about security, data protection and whatnot.
8) We’re a high-pressure delivery team.
Use Objectives and Key Results as hard, individual evaluation metrics. Don’t allow room for failure; learning has no monetary value. Hitting the target is all that matters. Ensure continuous feedback to point out how far behind the goals people really are.
9) We believe in hard estimates.
Expect accurate estimates and directly share those with the rest of the business, especially clients. Forget about Hofstadter’s law and Accidental Complication (and Complexity) because you work with people who’re supposed to be experts at what they’re doing. Failure to deliver within initial estimates is a sign of bad hires.
10) We get things right the first time.
Expect Engineering to produce high-quality code, fast and without too much fuss about extra time for invisible value like infrastructure, tests and automation. Cleaning technical debt is a myth perpetuated by programmers who want to work on cool new technologies.
What you could do instead…
1) Spend enough time understanding the problems you’re solving.
Invest enough time and effort upfront into understanding your users and the problems they have. Trying lots of low-hanging fruits might feel quick but won’t serve your customers much better than what’s already serving them well enough.
2) Split responsibilities between founders, executives and teams.
For example, use a framework like the Responsibility Assignment Matrix (RACI). Assign product ownership to someone with these six characteristics: Visionary, Decision Maker, Collaborator, Communicator, Doer, Knowledgeable. I’d reckon that Communicator is not enough, find a Storyteller instead.
3) Avoid ill-informed, snap judgements and push for more rigour in decision making.
Documenting decision-making in writing might give you the respite you need to at least consider the bigger strategy.
“If one person says that you’re a horse, smile at them. If two people say that you’re a horse, give it some thought. If three people say that you’re a horse, go and buy a saddle.” — Popular wisdom
4) Document important product decisions in writing.
When the context changes, document and share the new reasoning with the team, using simple PRDs and RFCs.
“One of the most important — if not the most important — job for a product manager is to define clearly and in as much detail as is necessary what the product should do, how fast it should be, etc. Good product managers don’t forget to specify critical information. Good product managers err on the side of clarity and are willing to explain the obvious to make sure it’s understood. Good product managers also specify the whole product, including release criteria, platforms, etc., not only the new features. Good product managers also sense and tackle hard issues — in writing — early in the development process.”
Ben Horowitz and David Weiden
The same goes for Engineering teams.
“In our day-to-day, we make small decisions that have little to no impact. The cost of undocumented decisions is hard to measure, but the effects usually include duplicated efforts (other engineers try to solve the same problems) or competing solutions (two third-party libraries that do the same thing). Enough small decisions can compound into a future problem that requires a large process or effort (ie. migration). Documenting these decisions doesn’t have to cost much.”
Spotify
5) Develop a prioritisation thinking system.
Use a system of priorities for feature requests, for example, from P0 (?) to P4(?). Formalise prioritisation thinking with tools like RICE, Value x Effort etc.
6) Understand where you’re going by collecting and analysing data.
“You can collect data with the product you have, not the one you wish you had. […] Being data-informed means that you acknowledge the fact that you only have a small subset of the information that you need to build a successful product.”
Andrew Chen
‘Looking at data without a vision is like a cat looking at a calendar’. Disclaimer: I’m not a cat. That’s a Romanian proverb. Use the vision to tell you where you want to go and the data to check if you’re heading in that direction.
Observe how customers “hack” your product or use the “Coming Soon” technique to get further insights but apply them to develop a strategy.
7) Involve the team early in product & UX discussions.
Use Dieter Ram’s 10 principles rather than the blanket wisdom of form over function. Get sign-off on essentials like security, regulation and compliance, accessibility etc.
8) Focus on the value delivered at a sustainable pace, not on estimates.
Understand that accidental complexity comes not only from crafting new solutions to problems but also integrating third-party code from dozens of tools and frameworks, which all get updated at incredible speed.
If you can’t remove estimates e.g. you’re working in a consultancy rather than a product company, explain to stakeholders why they can’t be accurate, manage expectations and be open to compromise to the deeper complexities of building software products.
Find a sustainable pace. Slowing down after peaks helps recharge the brain with creativity, sense of purpose and happiness of completion.
There is lots of bad advice and bad practices around when it comes to Product, Design and Engineering collaboration and if you’re taking any of the steps on the sure-fire guide, you are likely to mess it up, and your team won’t thank you. If however, you want/need to change things to avoid failing, try out one of eight suggestions instead and see what happens!
