When you’re building a product, it’s tough to avoid the distractions and stay focused. Getting your entire product development team on song is crucial to your success.
Over the past few years, I’ve worked for organisations of all shapes and sizes; Startups, agencies, large orgs. I’ve seen incredible high performing teams and disparate messes. There are a few key elements that rear their heads time and again; when done right can lead to great things, when done poorly can blow the whole thing up.
I’d choose a great team and a less exciting product over a fascinating subject matter and a bad team any day. I’m not talking about the skills and abilities of the team. They are valuable, but the functioning of the team is so much more important. I’m convinced the vast majority of people working in our industry are smart and have huge potential. The environment and support they receive are vital in unlocking this potential. The first step and a hard one for many is trust.
Trust by default
The most obvious trait of the inexperienced manager is micro-management. It’s such an easy trap to fall into. I know I have in the past. Ultimately, as a manager, you are responsible for the teams’ output. So it’s only natural to want to make sure that it meets your exacting standards. But there is no getting away from the fact this is a weakness. It’s a fast route to a demoralised, ineffective team.
Where to start? Start from the assumption that the team is made up of adults that are qualified to do their jobs. Give guidance, ensure everyone is crystal clear on their objectives. Empower them to make decisions. Only step into the details in the rare cases where the outcome is sub-par. If you need to intervene, do it. But there is nothing more demoralising than a manager whose actions show they don’t trust you to do your job.
Trust breeds empowerment, which breeds motivation and productivity. Control breeds contempt, saps enthusiasm and gets weak results. If you’re micro-managed and not trusted to get your job done well, you end up trying to placate your manager, not your end-user.
Clear shared vision and goals
Clearly defined goals, short and long term, enable efficient, effective decision making. Repeat them often. Once you have a vision that the entire team can recite instinctively, you can work together and be subservient to the greater needs of the company.
I joined a startup a few years ago, where the team was not in a healthy state. There wasn’t a clearly defined vision for the product, and there were fractures in the organisation. Sales, marketing, design and development teams were thinking in terms of what would make their area better. What would be the most elegant solution for them? What would make them look better?
With a lot of hard work and communication, we managed to turn things around. Once we knew what we were working towards, we could prioritise what would get us there. Conversations changed to focus on what was best for the company. Who had more capacity to take the load off a swamped teammate? Could we reduce the scope and kill non-core features? Could we get away with building a good-enough-for-now solution?
Test everything against this vision
Any time a request comes in, from a customer, an executive or a team member test it against your vision. If it does not move you towards your goal, then drop it.
No fixed roadmap
Fixed, long-term roadmaps are a fallacy. If you think you can accurately plan out what will happen over the next 6, 12 or 24 months, you are mistaken. Product development is a highly volatile environment. You always have new information to act on. If you commit to 12 months of a fixed, time-bound roadmap, you cannot react to change. Your competitors will. They will leave you in their dust.
In Shape Up, Ryan Singer makes the distinction between imagined and discovered tasks. Imagined tasks are what you think you will need to do before you have started building the thing. As anyone who has made a product knows, this is pretty much never what you end up doing. Discovered tasks are the real work you have to do. The things you discover once you have started. The we didn’t anticipate this taking so long tasks.
But I need to tell people what is coming
Of course, you do. I’m not delusional. Prefer themes over time-horizons. What does this mean? A theme relates to a customer need, a real, discovered need that you have uncovered. By defining your roadmap by themes, you leave scope to change and shift the definition of the features when you come to discover exactly what is needed. The closer the theme is to being needed to be done, the more in-depth you will define it. There is no point defining anything much further out. In 6 months, your whole landscape will have shifted. Invest the time only where it is essential to move things forward.
Appetite is key
Another theme highlighted in Shape Up is appetite. Before the team embarks on building a feature, they set the appetite for it. How core is it to the business? If it needs doing but is not a central feature, then it would have a low appetite. Get it done, but forgo the bells and whistle. A large appetite would be something that is the core problem that your product solves. So go the extra mile here. Ask whether it move your core metrics.
For me, this is the most fun part of product development. Reducing things down to the smallest version they can be and still solve the core problem. Can you hammer the scope down more, can it be cut entirely?
Make customers demand features
Andrew Chen writes elegantly about the next feature fallacy. This refers to the mistaken notion that you need to add the next killer feature, then suddenly everyone will start using your product like never before. Either you are close to solving a real problem they have, or you are not. If there is something they need to get their job done, they will let you know. The crucial features will come up again and again until they are impossible to ignore. Just by leaving new feature ideas and requests to one side for a few weeks can make a big difference. More times than not, you will never hear of this idea again. If it’s essential, you won’t be able to avoid it.
Embrace randomness and uncertainty
Building new products is an unforgiving and ever-changing game. You can get lucky with an average product, process and team. Conversely, you can have everything going for you and still come up short. Don’t just accept this uncertainty, but embrace and optimise for it. Run short, low investment experiments to test customer demand for features. Only when they give you a strong signal jump into building them out in-depth.
Don’t waste time on reversible decisions
Jeff Bezos wrote about decision making in one of his share-holder letters:
“Some decisions are consequential and irreversible or nearly irreversible — one-way doors — and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions.
But most decisions aren’t like that — they are changeable, reversible — they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.”
If a decision is reversible, you shouldn’t spend much time debating on if it is the correct one. Test it out and if it doesn’t work reverse it.
You don’t have to agree on everything. Indeed you shouldn’t. Healthy debate and conflicting opinions are signs of a healthy organisation.
Above everything, the key to all this is to be intentional in your actions. To continually ask the question of does this matter? Does anyone genuinely care about this feature? It’s easy to get swept away by the never-ending tide of things to do. But be intentional too about where to not spend too much time. Nobody wants to look back on their past year and think if only I hadn’t spent all my time on distractions.