When Product & Engineering Collide
I have purchased 14 books on Product.
I believe I am keeping Amazon in business these days.
Seriously though the reason is due to being passionate about the world of Product Management and wanting to hear perspectives from all over the world.
(Even though I’ve been told several times you learn by doing, not reading).
I decided that as I finish each book, I will post a single quote that made a lasting impression on me and describe my experiences, if applicable.
The first book I finished was in late 2021, and was perhaps the book that most Product Managers have read.
Inspired by Marty Cagan.
My biggest takeaway was when Product works with Engineers.
“The question isn’t
𝐶𝑎𝑛 𝑦𝑜𝑢 𝑑𝑜 𝑡ℎ𝑖𝑠?
𝑊ℎ𝑎𝑡’𝑠 𝑡ℎ𝑒 𝑏𝑒𝑠𝑡 𝑤𝑎𝑦 𝑡𝑜 𝑑𝑜 𝑡ℎ𝑖𝑠…?”
How many of us have gone to our brilliant Engineers starting our questions with “Can?”
This has opened my eyes to rephrase future questions in order to allow the Engineers do what they do best, build and develop Solutions.
I have worked with Engineers since 2006. Not in Product, but in Support.
I can tell you that many have looked down on me being I was the rare Woman in Technology that kept her computer hardware tools in a pink Caboodle!
However, the few that allowed me to ask questions were the ones that I was greatly appreciative of as they did not have an ego. They were patient, kind, and admired my curiousity.
In Product, I feel that Engineers can be quite similar to what I was used to over a decade ago in Support. However, if you treat people with respect, you usually get that same respect in return.
These are some of the ways I work with the Engineers at my company in order to earn their trust:
- Protect their time ⎆ I cannot stress this enough. Do you not invite engineers to every single meeting. Obviously they need to be apart of the planning and grooming sessions, however, if you are having a non-technical conversation with a vendor or stakeholder do not invite them. If necessary record the meeting and post it on a Confluence site. That gives them the power to watch the recording on their times and decide if it is useful or not from a development perspective. Always set agendas to help determine which key players need to be in attendance, and try to have other colleagues get in the same habit.
- Be Curious ⎆ As per the above quote from Marty, do not ask if they can build something, allow them to do what they do best and give them the space to innovate. (I had received a question as to why even care about how something is built, but you should care. Especially if you are working with integrations. You need to ensure that the problem you are trying to solve for your customer is viable given any third-party API limitations).
- Do Not Promise Dates ⎆ When working with your customers, do not promise them dates. It’s one thing to say “targeting” end of a quarter, but never give them a date in black and white. This stresses out your engineers and is an unreasonable expectation due to unknowns. These can include planned / unplanned PTO, resource capacity, and any other number of reasons.
- Respect ⎆ This is common sense. Everyone at a company should be treated with appreciation. At a prior organization, I treated employees the same as I treated the CEO. It is so much easier to work where there is not toxicity towards others.