Hi, my name is Andre. Welcome to my Newsletter, a (sometimes) weekly column on product management to get products from zero-to-one. If you’re a builder looking for harmony among (product) chaos, subscribe to get the latest Articles and PodDrops.

Subscribe now

Originally posted at albuquerque.io on Oct 30, 2019

After leading some product teams over the last years, I’ve found 7 issues present in the majority (if not all) of them. These problems were identified in multiple stages and models, from early stage to growth stage, VC-funded to bootstrapped, B2C to B2B. The “younger” these teams are (i.e. junior PMs or recently established groups) the more these problems cripple their day-to-day. In a follow-up post I will tell you what I’ve done with my teams to tackle these issues.

1. Weak communication between engineering, product and design teams

These teams likely started separately, maybe outsourced or highly siloed (to “protect their focus” 🤦), but the greatest blocker to building great products is communication not flowing. Signs of this problem are 1) People barely talking, 2) or talking about the wrong things, 3) not being involved early enough, 4) or not collaborating in key issues so they can be focused.

2. Projects, tasks, code and dependencies are disconnected

Maybe teams don’t use any development collaboration tools (Gitlab, Github, JIRA, Notion, Trello). Maybe these tools exist but not all teams use them. Maybe every team uses a tool, but there are different disconnected tools. Sometimes they do use the same tool but the projects are not connecting. Sometimes there is a tool, used by everyone, with projects connected, but people don’t know how to use it properly, or are indisciplined/unreliable. In the end, these tools are means to an end: communicating (especially async).

3. Teams care about dependencies too late

Rarely teams know 1) dependencies between tasks, 2) estimation of how long each block is going to take, 3) how is everything planned and mapped, 4) what is still unclear/unscoped, and 5)potential blockers for future development. And when this alignment happens it’s either too late 👴🏻, or when someone’s already stuck.

4. No thinking, planning and mapping before execution

The lack of proper kick-offs with everyone in the room alongside weak preparation from each person and team makes it a key issue. Architecture is not thought out, there are no specs or documentation, no endpoints, mocks or prototypes for teams to rely on, etc. Skipping these “artefacts” leads to subpar thinking, which drives to inefficient development, no dependency management, missing deadlines and missing estimations 🌪. In the end either you have a broken product, you deliver late, or both.

5. Different processes even within small teams

On priorities/work organisation: 1) the backend team goes “waterfall” and asks to not mess the order, 2) the frontend team does some type of sprint and speak with them when they’re done, 3) product is in scrumban because we know priorities change but we need order, 4) design is in “schaos” (scrum + chaos) because we need it for yesterday but suddenly shit happens and now we need this. On meeting/syncs/comms: some teams meet every day, others sync once a week, others communicate async, others wait for bi-weekly retrospectives. 🤯. Aside the communication being broken due to different “radio frequencies”, the big issue is this actually breaks the spirit of being one team. You don’t ship software alone.

6. [Design/Product/Frontend]-Driven Scoping

This tends to happen when shipping a product from scratch (Big Bang release) or a significantly large feature (Epic release). As humans comprehend better what they see, “junior” product teams feel more comfortable at scoping based on what design has worked or what product has imagined. Backend often follows this, often not being included in the early scope. The result is over promising and under delivering and failing to meet the deadline (even if “estimated”), as backend might take longer, slam into blockers or simply needing to find “new ways”. Another scenario is frontend starting first and suddenly having to throw stuff out when backend “arrives” because of scope changes or cutting stuff to meet the deadline. Inefficient and frustrating.

7. Scope-rigid and timeline-rigid

This is particularly recurrent in young startups, founder-centric companies or product-inexperienced executive teams. Top down decisions generally come as 1) you need to build PRODUCT X which has A, B and C functionalities, and 2) you need to deliver by DATE Y because of reason D, E, F. This approach is unfeasible because if you want to keep a rigid date, you need your scope to be flexible so you can cut stuff. If you need your scope to be rigid, you need your delivery date flexible because unexpected stuff happens (especially if the scope was decided by non-technical people or without the actual product/eng/design team in the room). What tends to happen is rigid scopes with rigid timelines.

What can be done?

I am following up in a future blog post what I’ve done to solve some or all of these issues. Nothing is 100% solved (and will never be) but it does make product team’s lives better (measured by quality of the product metrics and happiness of the team). As soon as this post is live, I will edit this section to include the link.

Share Albuquerque’s Newsletter

Albuquerque’s Newsletter

What makes young product teams suffer