post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

mission statement

Deep dive: Crafting your product vision and mission

Podcast

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Join us at #mtpcon London in 2025 – mark your calendars

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Building your own user experience and software stack: This week’s product news

Rob Boyett is Product Design Director at Idean UK (formerly Adaptive Lab). He's been working in digital product for over a decade, predominantly in the mobile space pre and post the smartphone revolution. His work spans across a wide set of sectors, including technology, fitness, cultural institutions, hospitality, home delivery and finance. Rob helped Sony Ericsson, The British Museum, Fitness First, Magic Leap design, build and ship great digital products. He also led the team that won the British Journalism Innovation of the year award for the iOS app Guardian Witness.

Rob Boyett

<img loading="lazy" decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2018/10/b379374e-7d8c-4f28-9660-e9bfc4032b53_image1.jpg" alt="" width="899" height="384" />
Team issues can have a negative impact on a project and your people long term.
There are a bunch of ways they might manifest themselves &#8211; and I’ve written them down as I’ve heard them over a decade of building digital products in cross-functional teams.
I’m not touching on the upfront issues like bad sales process, junk briefs, confused business requirements, that’s for another day. This list is most useful for in-flight project teams, off and sprinting.
Reading these unfiltered issues will surface the symptoms. And in turn, help with diagnosis. All teams and situations are unique, but some pains are universal and understanding the issue is halfway to a solution.
<h3>1 &#8211; &#8220;Our Client is a ☠️, They Don’t Understand What we are Trying to do&#8221;</h3>
This is bad mojo for a team. In the same way that losing empathy for the customer can easily happen in long projects (<a href="https://blog.prototypr.io/what-blocks-our-empathy-in-the-design-thinking-process-a09766198308" target="_blank" rel="noopener">good read here about this</a>), it’s easy for a team to start classing the client as a hindrance to getting a project out. This can creep in from the smallest negative comments.
If the team doesn’t take the time to understand who they are working with, an “us and them” mentality can develop. The client is taking great risks, personally and as a business. Building client empathy is important. They might be frustrated or confused, which can result in curt communication&#8230;
Tip: Get to know the client, learn to ask the right question and be patient. But most of all don’t be a promoter of negative views in the team.
<h3>2 &#8211; &#8220;Let’s Push Back This Next Check Till we Have More to Show&#8221;</h3>
This means the team isn’t confident in the direction they are going, and probably doesn’t have the right information. They’ll push the meeting back but go nowhere in the meantime, while the expectation gap between client and team grows and it gets harder to ask the simple questions they didn’t have the answers to in the beginning.
Tip: When you or the team are nervous of meeting with the client or major stakeholder, ask why and then go talk to the client about that thing.
<h3>3 &#8211; &#8220;Wow, I&#8217;d Never Seen That Document Before&#8221;</h3>
Projects will produce a heap of documentation, and that&#8217;s normal. This is a challenge worth understanding from day one. Light documentation in favour of delivering is (in my view) always preferable. One consistent issue I see is the grouping of deliverables by phase or sprint. This starts out looking like a good idea, but soon makes it extremely hard to view a continuous thread across the project.
Tip: By taking time to discuss where specific groupings will live, how insights will be surfaced, and an agreement on nomenclature, you will save time and pain later.
<h3>4 &#8211; &#8220;Our Meetings are Long and Have no Outcome&#8221;</h3>
It&#8217;s all-too easy to get into a bad meeting etiquette routine. If meetings feel long, then they are, regardless of their actual duration. Judging the correct length can be hard. The way the working day is broken into hours tends to mean a meeting will fill an hour (at least), irrespective of its content.
Setting a meeting goal or outcome is imperative. That could be to generate ideas, agree on a deadline or assign work. Whether the goal is hard or loose doesn’t matter, but having one is key.
Tip: The simple rules: set a goal, take notes, assign tasks, agree on next steps AND leave the tech out the room.
<h3>5 &#8211; &#8220;What did They go Into a Meeting Room for?&#8221;</h3>
When things get a bit “interesting” on a project there is a tendency to get secretive and have small groups heading to a meeting room. It could be a bit of client drama, or maybe a team member issue.
But quite often it&#8217;s just everyday tasks masquerading as an issue. The point here is that the rest of the team wonders what is going on. It creates team drama, and ripples from it are disruptive.
Tip: Try to be absurdly transparent. Spell it out. Tell the team at standup what’s going on and then say it again later. And where possible don’t hide in a meeting room. 
<h3>6 &#8211; &#8220;I Just Don’t get Enough Time at my Desk&#8221;</h3>
All the meetings, planning, and alignment are hugely valuable activities. But a balance needs to be struck. If your week is peppered with team meetings and check-ins, how can you find time to get deep into work? This crushes flow time, that special mode that gets the best work and helps team members to feel job satisfaction.
Tip: It’s worth evaluating the need for a meeting. If you are a manager, is this meeting more about your peace of mind than anything else? Could that be achieved in another way?
Another issue to watch for is the double workload a team can feel when working on-site with a client. Close collaboration is hugely valuable and something I would always promote. But it’s worth recognising that it comes at a cost to the team. They are always on, staying professional, interpreting comments and filtering needs. Once you have been doing this for a few years you find tactics to manage the load and it can be very enjoyable for most. But for members of the team more used to crafting at a desk with headphones on most the day, it can be a great deal of effort to manage and not feel the most productive.
Tip: Could you mark out safe spots in the week for the work to get done? I have gone as far as a traffic lights system in the past &#8211; I even had a traffic light on display. Parts of the week are green, free to chat and collaboration. Parts are red, please don’t disrupt, it’s deep working time. If this is planned in advance it gives the team a firm grounding to build out a week of work and know when they will be able to focus on the deeper thinking.
<h3>7 &#8211; &#8220;We Have a Presentation Today!?&#8221;</h3>
When people in the team seem confused about where to be and what&#8217;s happening this can be an indication of some poor calendars etiquette &#8211; things like moving meetings around without updating verbally, dropping them into calendars on the day or, even worse, five minutes before they start. This creates uncertainty, causes confusion, and quickly leads to a behaviour where you don’t start any major task because you have no understanding of how long you will have to work at it &#8211; why bother getting into it just to be pulled straight out.
Tip: Make time at the end of the day to plan your following day, confirm the meetings, and make adjustments. On the day, use a short team alignment like a standup meeting to get calendars aligned, and reconfirm all the key activities. Things change, people’s life commitments pop up. That&#8217;s all fine so long as the team are aware of where they are supposed to be ahead of time.
<h3>8 &#8211; &#8220;The Sprints Just Feel Relentless&#8221;</h3>
Sprints can feel quite intense and exhausting &#8211; whether it’s because there’s a deadline in mind, or no end in sight. This can be made worse when a team doesn’t have a grasp of the roadmap, or when you haven’t paused long enough to recognise success. One thing I’ve heard in the past which rings true, is ‘sprinting a marathon’.
Tip: One tactic is to have a break – a sprint every X sprints to focus on the little bits that have been sidelined, like process and documentation. This is especially useful for developers to jump on any technical debt.
<h3>9 &#8211; &#8220;Did you Take Notes? No, but it’s Cool, [Insert Firefighter] has it&#8221;</h3>
Teams that seem to not be taking responsibility are a really common and bad sign. Most likely a key person is taking the heat. Firefighter is a great term for the people who parachute into the troubled projects and save the day. They have a job to do and little time to do it, so their style is to dictate action. It works in the short term. Clients tend to love them.
But remember firefighters love to fight fires. It&#8217;s not necessarily on their to-do list to build a strong team. This leads to disengagement &#8211; why bother when the firefighter has it covered?
Tip: How you know if you have one  one person taking all the weight? Maybe the client said: “Where would we be without [Insert firefighter]. Don’t ever let them leave”. But what if they leave? Use the firefighter to set process, but then plan the day they move off the project with them. Let the team and client know. 
<h3>10 &#8211; &#8220;Best not Disturb the Team, They Have a big Mountain to Climb&#8221;</h3>
I have often heard this said by well-meaning managers. It comes from a good place. The team may have started strongly with retrospectives, but that can drift if not carefully guarded and valued. Not allowing the team the space to address problems weakens its ability self-fix. Resilience becomes low and the general mood can stagnate.
Tip: It’s time to get back to building the space to reflect. Gather input from the team on issues. You’ll probably realise they have a deep understanding of what is going on and that they have some ideas to fix it. Find a forum for discussion as a group. Empower team members to take action from those discussions, and always allow time for them to succeed at the tasks by building time into the plan.
<h3>…no time like now</h3>
If you have an issue in your team, and maybe one of these sparked that realisation, well good news! &#8211; one of the biggest lessons I&#8217;ve learned is that it’s never too late to take a moment, reflect, and start the conversation that could fix things.
As you&#8217;ve probably guessed, I don’t have any silver bullets for you – if I did I would have a book out 😀 Good luck 🙏

core/freeform

Reduce risk, fail faster: Experimenting across the product development lifecycle

Experiment like a boss by Merissa Silk

How to find out what your customers want by Janet Bumpas

Why does my product suck? by Jen Dante

Driving customer adoption and retention as a product manager by Karen Adie

Mastering the art of the big bet by Alice Newton Rex

The magic of thinking big by Lenny Rachitsky

Making magic with balanced teams by Becki Hyde

Tools for agile product teams by Gavan Moule

Building Products for Bharat by Arpit Maheshwari and Smriti Pant

What Product Teams say and What They Really Mean — 10 Tips for Diagnosing Team Issues

What Product Teams say and What They Really Mean — 10 Tips for Diagnosing Team Issues

Rob Boyett

Read more

Comments