Good habits superscale your ability to partner effectively with engineering.
As a Product Manager, it’s imperative that your relationship with engineering not only be good, but great. Great PMs have great relationships with great engineers — this is how you frictionlessly build excellent problem-solving experiences; especially at scale.
Read the original Twitter thread here, the Docswrite here, or the ThreaderApp unroll here.
1. Leading conversations with a well-defined problem or use case to explore
“Problem X affects Y users and I think we should do Z.”
Conversations with engineering should focus on a specific problem or use case. This will help avoid getting off-topic and also help explore different aspects of the specific problem domain.
A good way to start these conversations is by setting up a scenario or use case that will introduce the problem — this can be a simple problem statement or a complicated PRD. This will help engineering understand the context of the problem and enable them to best estimate the spectrum of approach (e.g. can we ship this with minimal tech debt? will this require a significant refactor if we commit to an early deadline?).
When leading this conversation, it is important for you to take into account everyone’s opinion and try not to dominate the technicals. Engineering should have the opportunity to contribute ideas and opinions, which may lead to a better solve for your problem.
2. Asking for an estimate and using that to drive delivery as opposed to arbitrary business deadlines
“How can we solve for X using Y in Z time?”
The first step is to identify the scope of work, which includes defining the key deliverables and timelines (see #1). The next step is to ask for an estimate from the engineer(s) that will be responsible for driving technical success.
3. Define atomic units of work that can be achieved in a set duration and creates minimal tech debt
“Problem X and Problem Y have Z in common.”
There is no one size fits all approach to this. The best way is to start with a small scope, identify the atomic unit of work, and then scale up.
The atomic unit of work can be anything from a bug fix to UI design change or even adding new features — aim to identify the common core between problems in the greater problem domain.
4. Cut cut cut with confidence
“What gets us to a minimum, minimum, minimum viable product?”
Most organizations do not have the luxury to launch every new feature or concept. Yes prioritization exists, but often collaborators, stakeholders, or customers will make valid cases across multiple features and you will be faced with a very difficult prioritization decision.
Cut cut cut with confidence — trim the feature fat and identify the requirements for core functionality of a delightful product. A minimum, minimum, minimum viable product — M3VP for short — should mirror the following:
- Fast — fast ideation, execution, and iteration
- Experimental — think big, test test test
- Solves 80% of the problem with 20% of the effort — Pareto principle
5. Don’t set your own arbitrary deadlines
“How long would X take? How long if we limited scope to Y? Or Z?”
Setting your own arbitrary deadlines is one of the worst things you can do for both your work productivity and the productivity of your fellow engineers. When you set an arbitrary deadline you’re doing your teams a disservice.
Problems are solved because we solve them, not because we partially solve them before an imaginary date and voila customers are happy. Strive for holistic, long-term problem solving.
6. Make habit of informing engineers with the “why” behind your decisioning
“Given Problem X, I am thinking about approaching with Y, because Z.”
Engineers are the backbone of any tech organization. They are the ones who create and maintain the products that we use every day. It is important to keep them informed about what goes on and why decisions are made. This will help them understand how their work fits into your goals.
They should be given a general idea of what they should do, but also enough freedom to make changes as needed (see #1–5). Engineers will be more efficient if they know why a certain decision was made, which can lead to better products for your customers.
7. Actively engage engineering in the customer feedback loop
The customer feedback loop is important to have a healthy relationship between you and your customers. It helps you understand their needs and find out what they want.
It’s not only the responsibility of product, sales, and marketing to get feedback from customers — engineers should also be involved in this process.
Far too often a HIPPO customer (Highest Paid/Paying Person’s Opinion) will use their spend as a means to stuff unnecessary features into the roadmap — you must protect your products from this at all costs, and it begins by actively engaging engineering in the customer feedback loop.
8. Involve engineering from Day 0
Engineers need to be involved in the design and development process as early as possible. This will help them understand what is needed, what can be done, and how to do it.
9. Have reasonable expectations
Think big, but be realistic.
10. Share the spoils of achievement
Give your engineers credit where credit is due!
11. Set clear expectations
“For X, I’m expecting Y or Z.”
People in engineering often get frustrated when they are not given enough information about a product or project. Set clear expectations and goals for what you want to achieve with your engineering team.
12. Realize tech debt is like real debt, and that you accrue interest which inhibits scale
It can be hard to realize how you are accruing interest on your tech debt because it’s not as tangible as traditional debt. But the effects are just as real and they can have a huge impact on your ability to scale your business.
13. Be reasonable
Engineers are not miracle workers. They are not magicians. They can’t solve every problem that comes their way.
The best thing that you can do is work with engineering and find a solution together, instead of expecting engineers to have all of the answers after a sprint or two.
14. Consider engineering contribution as solving for the known, the unknown, and the unseen
In my experience, there are three types of problems or pain points that engineers help solve: known, unknown, and unseen.
Known pain
Users are aware a certain pain exists and actively experience it.
- Frequent app crashes
- Poor search functionality
Unknown pain
Users are unaware a certain pain exists and actively experience it.
- Front end bugs
- Suboptimal personalization
Unseen pain
Users are either aware or unaware a certain pain exists and passively experience it.
- Data breach
- High latency
These 14 habits will evolve over time, yet the core message will remain: great PMs have great relationships with great engineers. That’s how you frictionlessly build excellent problem-solving experiences at scale.
