70% of features shipped have zero to negative impact. At Tadaa, we're helping teams develop robust processes to build products people want. We interviewed more than 250 product teams to understand how they operate (e.g. methods, processes, tools) and the pain points they endure most. Here are the insights.
This article is Part 2 of the "Product Life" Series. Check Part 1 here on product research and interviews.
3 pain points: scattered information, chaotic processes and young product culture
Product teams use on average 8 softwares (e.g. Figma, Miro, Maze, etc). The softwares work well as vertical tools to design, store knowledge, interview users, brainstorm etc. All product teams needs those tools to build products that work. However collaboration becomes much more complex when teams juggle from one tool to another.
This fragments the knowledge in multiple silos: between softwares, squads, and with wider business stakeholders. What we discovered is that those silos create complexity, frustration and chaos. This leads teams to build confusing products with useless features, higher costs, and employee discontent.
To overcome fragmented knowledge, we saw teams put in a place a rigorous documentation policy. Mixed with a no-meetings culture, the goal is to empower teams to work 100% asynchronously. Every decision and knowledge must be stored. What we saw is that overall product designers and managers spend around 60% of their time writing information, instead of focusing on problem-solving tasks.
71% of teams skip key phases (e.g. testing, analytics, research, etc) during product development. They might go faster, but it’s better to do it right than do it twice.
70% of products built have zero to negative impact
60% of Product teams feel they spend too much time thinking about how they should do their work (e.g. organisation, format, presentation, etc). This has a negative outcomes:
1. It squeezes the remaining time to work on problem-solving tasks
2. It increases lead time
3. It reduces the trust in decisions taken during development
The successful product teams we interviewed dedicate a high amount of their week to research and writing knowledge. Both tasks require planification and time. As a quick win they leverage templates available online (e.g. Miro) in order to quickly get to the interesting part: documentation and deliverables.
Product teams should take time and ensure processes are efficient when working on their first feature. By carrying retros at the end of sprints, it is easy to map out what worked and what didn't.
This should increase allocated time for problem-solving tasks and decrease lead time.
Being user-centric for teams means placing the customer at the core of your conception and development processes. While interviewing, we got interesting numbers on user-centricity in Product teams:
- When asked “How user-centric do you think your team is?”, 60% rated themselves as 3/5
- When asked “How user-centric do you wish to become?”, 90% answered 4.5/5
Overall, the vast majority (84%) of product teams want to be more user-centric in their approach to work, content and features built. However, they confessed they can't because they lack the tools, resources, and time to do so:
- Tools because current softwares are dinosaurs (next article) that do not work for the new distributed way of working that is here to stay.
- Resources because it takes time and money to recruit UX researchers, a data analyst, and to carry out user testing sessions…
- Time is an issue we hear often. Teams do not have time to reflect and improve their processes from one sprint to another and keep methods that don’t work. We will address this issue in a future article about lean management and agile ways of working.
Product teams also rely heavily on business stakeholders (e.g. customer success, marketing, data, etc) which have no knowledge on the product way of building features. Customer Success teams need to collect client feedback and share it with product managers and designers. However as they don't see how their contribution will help the wider team, they often lack motivation to share their insights. This reduces the quality of the discovery phase carried by product designers. Overall, poor communication between product teams and their stakeholders is the reason why 70% of features built have zero or even negative impact.
That’s a wrap! These were the 3 pain points 80% of product teams face daily. The +150 hours we spent listening to very interesting stories and collecting insights clearly highlighted a pattern from the smallest teams to the biggest scaleups when it comes to issues Product teams face. Coming up we’ll discuss why current softwares and working methods only increase these problems. Then we’ll see how teams can tackle them. Stay tuned!
Thanks a lot for reading this second chapter (First chapter on user interviews here) of the Product Life series. If you have any comments or feedback, please share! To learn more about the new collaborative product playbook we're building, you can check out Tadaa.