My Experience in Two Amazing Startups
I have been fortunate to have had the opportunity to work with two wonderful product managers at two startups. I noticed that they were both entrepreneurs, over-communicated with me, and made sure I was completely bought on the things we were building.
I was attached to these product managers; Together, we built facilities that generate millions in half the time and with a fraction of the manpower of fully resourced teams.
In this article, I share some lessons about what made this partnership so successful.
We shared everything. In my most successful partnerships, I talked more to my product counterpart than to other engineers.
The result was that we created a “universal data set” that allowed us to be completely on the same page about the problems we were solving in order to make the right decisions.
From PM, over-communication looks like this:
- insights from data analysis
- Submitting half-hearted ideas for feedback
- Sharing customer feedback (calls, emails, in-app surveys)
Engineered, this can take the form:
- Clarifying the technical approach to the solution
- Sharing context on data structures and system architecture
- Frequent sharing of estimates for different efforts to help prioritize
Over-communication is only effective with genuine curiosity and engagement. Asking questions about each other’s work helped us generate new insights that would not have been possible individually.
To the engineer, it means asking about “what”.
For the PM, this means asking about the “how”.
Example: I was prototyping a file uploader library from a service called FileStack (see below). I plan to use it for a specific facility to handle PDF uploads. I shared a demo of how the tool worked with my PM.
He was curious about possible use cases for FileStack and asked several questions about what else it could do. So we searched further into the API documentation and discovered image transformation and object-recognition capabilities that could help us with other business problems.
Although we wanted to use this solution to solve problem A, by showing my PM this technique he was able to think about how it could solve problems B, C and D.
With enough context-sharing and questioning, a prime minister and engineer can blur the boundary between their roles and wear each other’s hats (to an extent).
A great example is when my PM partner took the initiative to find his own answers by reading our codebase. To create a data dashboard for a feature, it needed to know the names of existing tracking events:
This freed me up a lot of time because I didn’t have to dig through the code much to see the event names anymore!
On the other hand, a good product manager is also looking for a thoughtful partner in an engineer, not just someone who can execute their vision. I tried to put on my product cap whenever possible to dive into data, discuss an idea, and ask as few questions as possible.
I go deep into an engineering perspective on contributing product ideas here: How to get good ideas without arrogance.
Great product managers are good at selling. They know it’s more useful to make buy-ins than steam-rolling engineers or making executive decisions.
With the best product managers I’ve asked “What do you think of X?” Like worked with proposals submitted in the form of questions. or “Does Y make sense?”
It made me feel part of the planning process and empowered me to influence the roadmap. When we reached a decision, I did a better job because I was invested in the result, not just the code.
Getting buy-ins isn’t just a PM’s responsibility – engineers need to tell the right stories to convince product partners that addressing technical debt or infrastructure improvements is the right priority.
For example, we recently wanted to re-imagine the UI of an important mobile app screen (see screenshot below). Unfortunately, the screen was a huge 3000+ lines-of-code React component, which in its current state would be hard to reorganize.
However, since we were already detailing more about the quality and condition of the various codebases, it was clear to the PM that we needed to invest in revamping this screen before making significant changes. Otherwise, we won’t be able to iterate quickly after the initial release, making life difficult for other mobile app maintainers.
With all of the above ingredients, you have the recipe for a quick feedback loop that allows you and your partner to make faster and higher quality decisions.
The following example illustrates these behaviors, where my PM and I try to clear up the confusion surrounding the message when a button is clicked in an internal support tool.
This exchange is a typical example of how we approach decisions. In 3-4 minutes, we did the following:
- Over-dialogue — sharing context on the issue, including screenshots
- Ask a question – what’s the problem? What variations can we try?
- Blur the line between roles—we both had an opinion on the right product messaging
- Avoid “Because I Said So” – Purchased Through Proposed Alternatives and Healthy Debate