6 Pillars for Building a Product Team

Earlier this year, I packed my bags and left NYC for the UK to join a startup called Simprints. After 6 years of building products at large Fortune 200 companies, I went to work for a young tech company that builds software and hardware to improve the distribution of health, education, and cash transfer services in remote regions of Africa and Asia.

I came on-board to build the product management team and guide the company’s product maturity through its growth stage. It’s been an amazing experience so far. The startup is growing. The product is improving. And everyday I learn more about what it takes to build an effective product organization.

Over the past 6+ years I’ve had the opportunity to build product teams from different stages of maturity: pre-market, growth, and re-building stages. Combining past experience along with using my current job as a frame of reference, I’m sharing the 6 key pillars I’ve found most helpful in building effective product teams.

1. Define Product through problem statements.

On my first day at Simprints I learned the exact reasons why the founders decided to hire their first product manager. The company had gone 2+ years without one. This is a long time without product but what arose during this time period were very clear pain points that needed addressing.

The following six problem statements are clear effects of not having a product team:

• Lacking inter-squad alignment on what and when to build things (+ backlog prioritization)
• Overcommitment — lack of clarity on product spec and capacity
• Development Time Drain — too much focus on the what & working with business
• Lack of request clarity- between ops and tech (bugs, client requests, support, etc.)
• Poor visibility across the team on the tech backlog and priorities
• Ownership issues- too many meetings/lack of buy-in

These pain points are incredibly useful criteria to help a product leader assess where their team is most effective and where there is room for improvement. Which of these problems are you currently trying to solve?

2. Build empathy. Fast.

Our product is used in places such as Ethiopia, Malawi, and Nigeria with the goal to improve aid distribution (i.e., immunizations, microfinance, education services, etc..). I am not the standard user of our product, but I could still go see the user, interact with them, and build empathy.

Within 4 days of joining I was off to Africa, adding a helping hand for a few team members deploying our technology. I was seeing the people and the tech in action, and even going on sales meetings, discussing how we could help other NGOs & governments. I felt like I was in a wind tunnel and running at the generator. It ended up being invaluable for 2 reasons:

1. I built empathy for our users. There is absolutely no way I could do my job well if I didn’t truly understand how our technology impacted our users’ lives. And I would have no way to prioritize what was important vs. what was not.
2. I built empathy for our product. I’ll be the first to say that I can sometimes be too critical. Being in the field and witnessing the impact the technology was already having, made me a much better teammate when we would encounter really simple bugs. Sometimes there just wasn’t time for the simple bugs. Seeing it in action made it painfully obvious why the small things — although important to acknowledge — will sometimes come second to tackling the big needs of our users.

3. Implement small, think big.

Half of the engineers joined this startup right out of school and had no experience with product or agile. Most of the business came from international development where tech wasn’t the focus of the company. I shouldn’t walk in the door and start spouting frameworks & principles and declaring that there is a better way (although I probably did this a few times). Bringing the team along for the journey will ensure people are being heard. Don’t work behind closed doors.

My suggestion when trying to implement frameworks is to actually start by deconstructing the framework into small chunks before sharing the end goal. If you want to build a strong scrum model, I would start by thinking about the paths of least resistance to change. Re-making engineering and product teams to align around the product? Too big and disruptive to start there. Adjusting how we communicate using stand-ups? A better place to start. Identify all of the changes you want to make on a scale of least resistance to greatest resistance. As you make your way left to right the acceptance of change will increase (under the assumption the changes have been effective) and allow for you to implement larger organizational changes.

Gaining Trust & Momentum

Examples of a small and big change:

• Implement consistent stand-ups. Our 3 teams (mobile, cloud, hardware) ran separate stand-ups. I asked them to combine these into one. A couple benefits came out of this: 1) The teams could start to interact more, be aware of the dependencies, and build cohesion. 2) It was easier to slowly introduce standardization and efficiencies into how stand-ups were run. And 3) as a bonus, I gained a clearer understanding of all aspects of the product in one place. We are now splitting them back out, but instead of splitting them out by expertise, we are splitting them out and aligning to product output.
• Spend a few months implementing and executing the pre-existing product vision or pipeline — just making small changes to prioritization, requirement writing, etc… along the way. Once I was familiar with the tech stack, with existing backlog of requests and stories, I started formulating a clearer vision for the product. I looked at our landscape, the makeup of the sales pipeline, the scale of our platform, and collected the opinions of the right voices in the company and then recommended a path forward along with a co-founder. It helped expose some serious discrepancies in peoples’ visions. However, after we shared detailed research and implications to the company and then hosting a workshop, the team went from individual interpretations of what we do, to an explicit product vision and investment for a 12 month runway. Spend the time to make your product vision hyper clear and reinforce that decision frequently.

4. Be calculated about the people you need in your team.

It is important to draft up what you want your team to look like, but be creative and nimble about how you achieve that growth. Don’t view a growing team as a success. When you have to be incredibly smart with how you use a startup’s limited money (or a company of any size), always ask yourself the question: “If we do not hire for ‘X’ position, will we see a unsustainable drop in team satisfaction and a stagnation/loss in users (or sales)?”

When you demonstrate a logical frugality, when you really do need to hire someone, the company listens and it becomes much easier to get the green light to hire.

5. Drive for clarity.

If you are new to the team or to your organization, it is a perfect opportunity to be inquisitive. You are expected to ask questions, probe deeper about misalignment, and drive for clarity. I found it useful to probe and ask questions to unearth any discrepancies between how one team assumed something worked and how it actually functioned. And when it comes to building great products, the PMs job is to ensure that conceptual knowledge is thrown out the window and that true, foundational knowledge is the only mode of operation. This means asking questions that might feel have obvious answers or may expose a gap in your own knowledge. That is OK. That is our job. A moment of personal vulnerability can save a massive technical vulnerability from going into production.

6. Embrace the bugs.

When working at a fast-moving startup, bugs are inevitable and frequent. However, you learn more per-minute-spent-on-bugs than any other concentration of time. You see the vulnerabilities in the architecture, you identify the best testing protocols, you dig in for long periods of time with your engineers to derive the root cause analysis, produce a solution, and handle the complexities of the release politics.

There is no better way to build a resolve and mutual respect with your team, and see where there may be cracks in the armor. Appreciate these moments, I find them as holistically valuable.

Thanks for giving this a read and please share your thoughts below. Would love to hear what other actions you’ve taken when building great product teams.