One of the great benefits of a client services company is that you get to see the insides of lots of different organizations — small to large, startup or established, scrappy to well-funded. When we get brought in to help solve a big problem, we learn about the workings of the org nearly as much as the software platform we’ll be working on.

As we’ve partnered with companies across different industries, we’ve noticed recurring themes in the issues that hold product teams back from doing their best work. Some are harder to recognize and dislodge than others; some are operational, while others are more about mindset. Here we’re going to share the top six mistakes we see product teams making, and our best advice for addressing (or avoiding!) them.

Mistake #1: Being vague about your timeline and commitments

The agile development revolution brought a sense of freedom to teams building the software. Many engineering teams embraced the idea of iterative improvement over waterfall planning, throwing out their roadmaps in favor of two-week cycles and sprint demos. It’s tempting to think that not having a timeline with firm commitments is great — you get ultimate flexibility! But the ambiguity makes it harder for other parts of the org to plan around the product, and stakeholders start to lose confidence in what’s coming.

Solution: Be transparent and specific about the work and the plan.

Sales, marketing, editorial, and customer support all have their own roadmaps and need clear timelines from builders to align their promises with what’s coming in the product. Establish a monthly roadmap and communicate it far and wide. It doesn’t have to be exhaustive — in fact, it shouldn’t. Leave some room for change while still giving a clear sense across the company about the milestones up ahead.

Mistake #2: Waiting too long to ship

We see so many product teams who are waiting for everything to be right before shipping a new release. It’s a flavor of perfectionism — the instinct not to take your product to market until it’s completely buttoned up. But we’ve found that it is far better to ship an incomplete product for the sake of feedback so you can learn and iterate.

Solution: Try a beta program to get new features in the hands of users.

There is no substitute for real usage on your product. You’ll learn things from real people using your product that you’ll never hear in a design review or a user interview. Try putting the next feature on your roadmap out in beta. If it’s too big, break down what you’re working on into a smaller, useful, shippable thing.

If you’re working on a larger platform that hasn’t seen regular updates in a while, reboot it by establishing an every-other-week release cycle for bug fixes and small tweaks, instead of holing up for a months-long (or years-long) rebuild. Just seeing some momentum build will start to earn back confidence.

Shipping also builds trust. As other groups in your company start to see that your team is consistently putting out software, they learn that it is safe for them to rely on steady progress in the future. Shipping empowers your sales and customer success teams to point to the newest features, even if they’re only in testing with a limited customer base.

Mistake #3: Neglecting your tooling

How many times has your team been frustrated with some aspect of their setup, but agreed that it’s fine for now and kept going? Those things add up. Both deficiencies in the process — we don’t have clear error reporting — and ineffective parts of it — we write these docs because it’s what was done before, even though no one really reads them — are drains on the team that surface daily and have a cumulative effect.

Solution: Schedule regular time to improve your team’s setup and process.

High-performing teams need to rely on their tools to enable them to move fast and without bloat. Dedicate time for your team to get together and take a critical look at setup and processes and collaborate on improvements. Here are some things to touch on:

• Error reporting and debugging tools
• Clear code review process
• Easily understood and accessible design review and sign-off
• Regular use of a copy of production data in dev and staging environments
• Branch deploy previews
• Continuous integration, even for in-process work
• Fast, as-minimal-as-possible issue tracking
• Updated and concise documentation (consider: Basecamp, Confluence)
• How you use Slack as a team

This takes some time to get right. It needs a dedicated kickoff session and built-in time every month to revisit and invest in the tooling setup. Evaluate team behaviors, too, and especially look for things that aren’t working anymore that you can stop. Your team will be repaid tenfold for the time investment you make.

Mistake #4: Single-sourcing your QA (or not doing it at all)

We’ve seen all kinds of quality assurance teams. The least valuable ones are just clicking through a script, following rote instructions, and never gaining an appreciation for the product they’re testing. Even with good QA folks, though, any one person will inevitably have blind spots.

Solution: Distribute QA testing across your whole team.

Distributing QA builds investment in the product and reminds team members on a regular basis about the customer experience of the front end. It’s an idea similar to “everyone does customer support once a month” — that connection is important context to the individual features being worked on every week.

The best way to do this is with an open-ended test plan that gets assigned in a rotation. It should be short (less than 20 minutes to complete) and each person on the team has a day to complete it. It should be outcome-driven (e.g., “post an article in the CMS with three supporting images”) instead of scripted (“start a new draft, write the headline, click the insert image button…”). And before major releases, one way to scale up this idea is to have the whole team do a more in-depth test.

Mistake #5: Giving into the “feature chase”

Good teams can easily be led astray by what we call “the feature chase.” Customers keep requesting new things, and so the product team diligently just adds those features to the platform. Good news, right? We’re delivering what our customers asked for!

Well, caking on every feature that’s possible leads to bloated, unusable software that often needs to be unwound and redesigned (the customer is not always right). Customers will often ask for things that are rarely or never actually used, so there are countless products that have high usage on 15% of the product and no usage on the other 85%. User research is often misapplied in this way. Talking to customers is good, but what you learn in those sessions needs to be evaluated.

Solution: Use critical design thinking to solve customer problems.

It’s the responsibility of the product team to bring good design thinking to bear on what you hear from customers, and then offer solutions that address the underlying problems, not just the most straightforward application of the exact request. As that old saying goes: Give me what I want, not what I asked for.

Next time you talk with customers, change your questions in order to hear their problems, rather than solicit new features. Afterward, schedule internal sessions to regroup about what you just heard, and try to identify trends across interviews. Even better, bring concept designs and prototypes to your customers to validate them and see what works (and what doesn’t).

Mistake #6: Forgetting to market your product internally

This is the trickiest one. So many product teams we’ve worked with at larger companies forget that the priorities of their team may not match (or even be clear to!) the other teams in the company. There’s an assumption that everyone knows what’s going on, but it requires investment from leadership to communicate those ideas across the company. Demo sessions (“we’re agile,” I can hear you all saying) also don’t work without investment, because frankly people tune them out.

Solution: Invest in internal marketing just like you would for the outside world.

Talking about your team’s focus builds goodwill with these other teams. It lets the company share investment in the product and contribute to what’s ahead. Let me be clear: This requires effort! In order to make this effective, you’ll need to dedicate time and resources to making good assets and taking the time to share them in meetings and written communications.

We’ve seen success with monthly presentations that are clear, polished, and put together by a designer. Other good techniques are sharing stats on usage, distributing short videos of new features, and meeting 1:1 with customer success people or sales folks to share what’s upcoming.

Chris LoSacco is a Managing Partner at Postlight and the head of product. If you want to talk about a challenge at your org, drop him a line at hello@postlight.com.

Want to hear more? Listen to Chris and our cofounders over three recent podcast episodes that dig deeper into all six mistakes: Part 1, Part 2, and Part 3.