The magic loop — how to improve your product team continuously
In the last articles, I emphasized how important communication and context are in product development. Today I want to focus on my favorite benefit you get when you follow the advice I was giving in the past.
There is this strong belief that the number of people hired somehow represents the growth and success of a company. I even heard about investors who asked for that number and considered a low one to be weak. On the other hand, we all know the stories of startups where laydowns are the last chance to survive after hiring too many people too fast. A situation you don’t want to find yourself in.
Of course, laydowns are close to the worst-case scenario. Another, more common, side effect of hiring too many people too fast, is the “feed the beast” problem. All these talents need work. To keep them busy and to utilize them, at least by a hundred percent (or like some bosses believe, better 120%), you will skip product discovery or at least compromise on it. It’s a direct way into the build trap. You build feature by feature because you have the manpower to do so. In the end, you have a product “Frankenstein” which isn’t delivering value, but a lot of complexity.
A good product team needs nothing more than one product manager, a product designer, a tech lead, and two to four engineers. The exact number of engineers depends on the skill level. I prefer to work with full-stack developers where each team member focuses on special expertise and shares her knowledge with the other team members. In growing companies, you can organize those experts across teams. But that’s a topic for later. I also prefer to have an even number of engineers to enable them to work in pairs as much as possible.
As Marty Cagan describes in his book “Inspired”, the core responsibility of a product team is getting the answers to four critical questions:
- Will the user buy this (or choose to use it)?
- Can the user figure out how to use this?
- Can our engineers build this?
- Can our stakeholders support this?
We call this process product discovery. We come up with ideas on how to solve our customer’s problems and we try to confirm upfront if whatever we have in mind will work. Then, and only then, we would start to build. That’s also why I recommend to — and expect from — experienced developers to ask for the proof that whatever they are asked to build will work. In good product teams they would know this anyway, because they are part of the whole discovery process.
Why do I tell you this? Well, in good product teams, product discovery (what to build) and product delivery (how to build) work in parallel. It’s called dual-track agile. But there is still a high chance that the team members will experience idle times. They have to wait for the results of an experiment, a customer interview, or something else. It will happen and there is a high chance that people will ask for more work. If you would now give up on your principles of being focused, you would already start a new topic. Don’t do this. There are many reasons why focus is such an important aspect in product development. Again this is food for many new articles. For today I just want to provide you a link to a conference talk from Henrik Kniberg. It’s one of my all-time favorites and explains the relevance of being focused pretty well.
https://youtu.be/n7wH2XdOWpM?t=831
Instead of feeding the beast, learn to make use of idle times. I believe that people should never be utilized more than 80%. But what to do with the other 20% you ask? It should be all about improvement. Improving the team and improving the individuals. Do our processes deliver the value we expect? Are there tasks we could automate? Are there new skills we could learn? There are endless opportunities on how to improve as a team and as an individual. Make sure that the improvements will contribute to your goals and create value. If you do so it will provide you with a high return on investment.
I call this whole process “the magic loop”. Because focusing on improvements during idle times will automagically end up in more idle times and therefore more improvements.
Instead of recruiting more and more people and keeping them busy, you will start to create a product machine that is able to create more impact. Impact on your product and thus also on the business.
Even more relevant is also the impact on your team. First of all, people want to grow. Giving them the freedom and time to do so will also increase their happiness. Second, because you don’t need to hire too many people you will also be able to compensate your employees better and better over time. Reducing employee churn and increasing their impact will give you a big advantage over time.
I started this journey by introducing a so-called learning day to the team. One day, every two weeks, where the team was allowed to focus on whatever they wanted to learn. It was a huge success and we changed from every two weeks to every week. Later I learned that having a dedicated day is not the right approach. You should not wait for a specific day to learn and to improve and you should not ignore important work during that day. So I ended up with the concept of utilizing idle times instead. It enforces continuous learning and fits with the current workload.
When I look back on my career so far I would consider this learning as one of the most relevant ones. I also know that it sounds simple but it isn’t. It’s a process, and in the same way as you have to manage non-idle times, you also have to actively manage idle times. To learn and to improve, people need guidance. As mentioned in my last article, setting the right expectations is a great starter for this exciting journey.
What about you and your teams? Do you do something similar? What are your experiences?
