How (some) A* teams get shit done!

We spent last month talking to dozens of teams from companies like Shopify, Dribbble, Ritual, Pastel, and Microsoft as a part of our product design process for Clew. While this has been essential to building an effective collaboration platform for teams; it also taught us a few things about how high-performing teams stay on top of their game.

Here’re a few things that make good product teams great.

1. Good communication

Everyone needs to be on the same page. Good product teams rarely make top-down product decisions. Instead, they debate new ideas; discussing purpose, outcomes, and implementation. The designers talk about UX implications, the data scientists share possible impact on conversion and the developers discuss implementation challenges and answer questions like who’s best suited to build it, and how to segment the work amongst them.

What separates the A* teams?
Good product managers empathize with their team members. But, that doesn’t mean you’ll know enough to tell everyone how to do their job. Great PMs engineer their team dynamic to make their own decisions by laying down processes to capture everyone’s ideas, feedback, and opinions.

Some teams members are more introverted and agreeable than others; they may not be the first to share their opinion or start a debate. A* teams make sure everyone’s included by taking votes (🂡🂢🂣🂤🂥) or going in a circle giving everyone a chance to share their thoughts by default.

2. Reliability

Teams work because everyone *individually* gets shit done. While part of this is simply hiring the right people, the rest is predicated on setting clear expectations and defining objectives. Make sure everyone is aware of what they should get done and when they should have it done.

Teams typically organize around a project management tool where they track their stories, issues, and features. Creating cross-dependancies across objectives and defining a workflow for taking new ideas from discovery to possible solutions and development is key.

What separates the A* teams?
Your team has a goal, and individual members have objectives that work towards achieving that goal. Sometimes objectives are dependant on each other and it’s important for the entire team to have an idea of the progress you’re making towards the goal. A* teams reinforce this through (daily) stand-ups where everyone shares what they’re up-to for the day and the progress they’ve made.

Having a properly setup product management tool like Jira or GitHub projects that can give anyone in the team a birds-eye view of progress is also very important.

3. A central source of truth

Well, this one’s a tough. There’re 6000+ different SAAS tools in the market. Your average team will use 10 different tools for their day-to-day work; GitHub or Bitbucket for code, InVision, Sketch and Figma for design, Datadog, Mode and Google Analytics for data and Drive, Box or Dropbox are just a small sample of the suite of tools that your average team uses to store their files, track work and communicate online.

There’re 6000+ different SAAS tools in the market. Your average team uses 10 different tools for their day-to-day work.

Don’t get me wrong, having so many choices is great! There’re specialized tools for everything! But, this also means information and communication get siloed in different tools and the average person has to have multiple tabs open at any given time to get the information they need for their day-to-day work. This is daunting.

What separates the A* teams?
This is a classic organizational problem that no one’s managed to definitively solve. The task of keeping track of files and information from different sources comes with a tonne of technical overhead and unreliability. Some teams we talked to put all the files related to the work at hand onto a Google doc and maintained that as a central source of truth. While this is a mediocre solution at best, it does get the job done. It’s one of the reasons we’re working on Clew; to build a more definitive solution to this specific problem.

Shameless plug. 🤷‍♀️ — Get some access at https://onclew.com

4. Iterating on good processes

Product management is all about having well-defined processes that everyone’s aware of. Most teams we talked to had processes that everyone was aware of. This speaks partly to the points I touched on above with reliability and defining workflows, but, it’s especially important when you need to adapt to changing market signals and meeting short deadlines that can make or break your product.

What separates the A* teams?
They don’t make up their mind about processes on day 1. They constantly (and quickly) iterate on everything from tooling to day-to-day processes. Just like your product; it takes iteration to figure out the right flow-state for your team.

5. Knowledge sharing

Good teams are made up of specialists who’re really good at one or two things. But, for them to work within a team they also need to understand everyone else’s work to some degree. At Shopify they described it as a T; as in, goes in-depth on a few skills, and have a shallow understanding of a lot of other things. As a part of a team, this means you’ll be able to empathize and set reasonable expectations for the people you’re working with.

What separates the A* teams?
Great teams share knowledge. Naturally, if you share the same workspace, everyone learns a little about each other’s work. The developers help the data folk write SQL queries and the front-end engineers tell the designers about CSS grids (yes, they’re kinda amazing). This reduces friction from inter-role communication and helps your team work seamlessly towards common goals.

This is harder to replicate across a distributed team. By far, the best solution is to make it as easy as possible to ask questions and start conversations using tools like Slack and Zoom that makes it easy for anyone to ‘ping’ anyone else in real-time.


Obviously, this isn’t a completely representative sample. At the end of the day every team is unique and you need to figure out what works best for them. For example; this probably won’t be the best advice for a production engineering team that works on high priority issues with strict guidelines. But, when it comes to product teams that own a single product or set of features — the above set of principles seem to work very well.

If you found this useful we’d love it if you recommend and share the knowledge.✌️Come find us at @ClewHQ