3 pain points all Product teams face
Product teams are great at tackling their customer’s problems. Why aren’t they better at solving their own?
Hey I’m Ed, co-founder of Tadaa. To iterate on the problem we’re tackling with our collaborative workflow, we carried 50+ interviews with Product teams. They shared 2 key elements: how they work (e.g. processes, tools, etc) and the pain points they endure. Here’s my takeaway on the most common pain points product teams face, enjoy!
This article is part 2 of the Product Life series. Check part 1 here on product research.
TL;DR: All 3 following pain points come from the almighty trade-off every product team face: Speed vs. Quality
1. Lead time
Why must all PMs, Designers and Engineers decide between going fast and delivering a feature of high quality? Lead time.
Lead time is key when building new products. It is the difference between when a customer asks for a specific feature, and when it is delivered.
80% of teams interviewed admitted that for each step of product development they constantly choose between speed and quality. They shouldn’t:
- Speed is vital in lean management, but building for the user is top priority. If you deliver a product in 2 weeks that customers don’t care about, you’re just wasting resources.
- Most product teams don’t monitor conversion rates after product is launched (or don’t have any incentive to do so), so they often take the easy shortcut of being less customer-centric during conception stage.
This results in 71% of teams skipping key phases (e.g. testing, analytics, research, etc) during product development. Sure they might go faster, but it’s better to it right than do it twice.
2. Way of working vs. actually working
60% of Product teams feel they spend too much time thinking about how they should do their work (e.g. format, structure, presentation, etc). This has a double negative outcome:
- It squeezes the remaining time to work on problem-solving tasks
- It increases overall lead time
Successful product teams we interviewed dedicate a high portion of their week on Research and Writing knowledge. Both tasks require planification and time and should not be omitted. A quick win would be to leverage templates that are available online (e.g. Miro) in order to quickly get to the interesting part.
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 works and what doesn’t. After that, their time spent on problem-solving tasks should increase in order to slowly 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 some pretty 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/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 couldn’t because they lack tools, resources and time to do so:
- Tools because current softwares are dinosaurs (next article) that do not work for the new hybrid way-of-working that is here to stay.
- Resources because it takes time and money to recruit a UX researchers, a data analyst and to carry user testing sessions…
- Time is an issue we’ve heard a lot. Teams not having time to reflect and improve their processes from one sprint to another, and keeping methods that don’t work. We will address this issue in a future article around lean management and agile ways of working.
That’s a wrap! These were the 3 pain points 80% of product teams face daily. The +100 hours I spent listening to very interesting stories and collecting insights clearly highlighted a pattern from the smallest teams to the biggest scalups 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 here), of the Product Life series. If you have any comments or feedback, please share! To learn more about the new collaborative product workflow, please check the tool we’re lauching to build products together.