Instructions are for furniture
Ideas are a thing of beauty. They can take many forms, shapes and sizes until someone has the chance to write something down either on paper or an electronic resting spot.
Have you ever had a brilliant product idea that’s actually been taken forward and delivered into a product? It’s wonderful feeling.
Knowing that your brain spat out an idea that is being used, joyfully, by tons of users is something that should spark pride in any human who just so happens to be part of a product building group.
Have you ever had a brilliant product idea that turned into some bloated and often underestimated mess of a feature that is either iterated on until it makes sense or is even worse, not used by anyone.
What’s the difference between how both ideas are written down, communicated and then delivered? There could be no difference.
Brilliant ideas which are fantastically delivered sometimes don’t work… that’s part and parcel of building products. In fact it’s an amazing piece of learning to realise that something the team thinks the customer wants… they actually don’t really care for.
Working software over…
I’m sure you’ve heard this one before, but it rings true.
Working Software Over Comprehensive Documentation
Spending days writing the perfect JIRA ticket specification to then have it signed off by the business and then finally started is a legitimate time suck in many organisations.
In todays world, the needs of the business change rapidly and that means the group working on products need to adapt to ever changing requirements because we welcome them.
Highly specified requirements that haven’t been seen by the team are also particularly uninspiring to deliver. The craft of building something gives most folks in engineering a sense of purpose, ownership and joy. Handing out pre-determined specifications which reduce the need for someone to use their brain is like handing instructions for a wardrobe to a carpenter.
She can do it but it won’t be the best use of her skills.
Sooner, not faster.
There is a ton of material and evidence to support the notion that adding more folks to a feature, sprint, team or group working on software won’t make it go any quicker.
Mythical Man Month.
Brooks’ observations are based on his experiences at [IBM] while managing the development of [OS/360] . He had added more [programmers]to a project falling behind schedule, a decision that he would later conclude had, counter-intuitively, delayed the project even further. He also made the mistake of asserting that one project — involved in writing an [ALGOL] — would require six months, regardless of the number of workers involved (it required longer). The idea of putting a feature or idea out sooner is also quite well documented, but often overlooked. What does faster actually mean in the picture of building software? It means you are bursting towards the end and likely out of control.
Sooner is about deploying after your first iteration of the idea… even though it may not be ‘done’. Feedback sooner allows for validation on the idea to reduce any waste in going forward with something that shouldn’t go any further.
When you think of a team, do these come to mind?
Disengaged? Unaligned? Siloed?
A team is a collective group of humans who are working together day-to-day towards a shared goal. They use that shared goal to validate their decision making to make sure it aligns to their North Star.
Maybe you work in a group or department… that’s not a bad thing; it’s just not a team.
Now when that goal is aligned to a product, the ideas become less precious. Those brilliant ideas either take you closer to the goal or they don’t… that is all they need to do. If an idea doesn’t work, the learnings are taken and other ideas are born.
So the next time an idea of yours doesn’t work, don’t take it personally. What is worse… knowing it doesn’t work or forcing a group into spending their time building and supporting an idea that nobody uses?