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:
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:
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.
Examples of a small and big change:
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.