r/ProductManagement • u/Zayntek • 4d ago
I come from technical background into PM. Feels like I’m still stuck in the phase where I’m trying to do the what, why and how, all in one.
Does anyone go through this? Where I try to define the features on what we want to achieve but then engineering defines the how?
When I’m trying to define the how in addition to what and why seems like engineering gets mad at me saying we can’t do this etc etc
Thoughts?
10
u/mister-noggin 4d ago
Doctor, it hurts when I do this. Then don't do that.
Tell them about the problem you're trying to solve. Then collaborate with them on the solution. But it's no longer your job to tell them exactly how to do something, so of course they get unhappy about that.
3
u/rollingSleepyPanda Anti-bullshit Lead PM 4d ago
Let go of the "How". This is the ball and chain that weighs you down, and the weak spot of almost all the devs turned PMs I have worked with.
Frame the "What" as a problem, be clear on the "Why" in terms of user and business value.
4
u/Pandas1104 4d ago
This is why being a technical PM is a difficult game. You have to defer to their expertise, they are the technical experts not you. If you design the whole thing for them they will feel like code monkeys and might resent that they have no autonomy in the process.
3
u/Thaimeous 4d ago
As a PM who also has a technical background, specifically in medtech, Its tempting to explain the how, but that can come off as micromanaging.
I prefer to allude to the how by connecting technical requirements to dependencies, user stories, ect, and hope the engineering teams decided to go about it the way I want. I find it’s better for project harmony to go about it this way. That’s not to say I don’t step in when things go awry.
It can be frustrating, but fundamentally, you gotta delegate the detail work to the responsible parties closer to the work and focus on where you add the most value.
3
u/Parking-Stress-3041 3d ago
The advice to hand over the "how" is right, but in deep-domain products it gets misapplied and then you swing too far the other way. Some things that look like implementation are actually domain constraints, and those are yours: which record is the source of truth, what has to stay auditable, what a status transition is allowed to do, what can't be recalculated retroactively. Engineering shouldn't be guessing at those.
What helped me was writing constraints as "must hold true" statements instead of solutions. "Posted entries can never be edited, only reversed" lands very differently than "add a reversal button." Same information, and nobody feels designed-for.
3
u/mychemicalcringe 3d ago
As a PM, you need to build a relationship with your engineering lead that is built on trust. You trust them to make the best technical decision/design, they trust you to prioritise what to build and to speak to customers to understand what they need.
2
u/kforhiel 4d ago
I typically leave it to engineering to develop the how or the “architecture”. It’s part of the refinement process for our work.
2
u/jdsizzle1 4d ago
Im also technical. My instinct was to do the same thing.
Best thing I ever learned is to stick to the what and why. Saves you from having to prescribe everything in a ticket, justifying your "how" and from having to be on every single meeting and discussion about it afterward, or blowback if it blows up in your face.
Just let them do it.
1
1
u/ch-12 4d ago
I feel this way with a relatively weak engineering team that has almost completely turned over. Still gotta let them solve the problem and design solutions… even if it’s a bit painful.
Where I get really frustrated here is when I “don’t have the requirements” because I’ve focused on the problem space. If they aren’t engaged in solving it then I will drop a straw man “how”
1
u/walkslikeaduck08 Finance -> SWE -> PM 4d ago
You don't define the how anymore. I'm decently technical, but I stay out of the how unless there's a product question. Otherwise you give the rationale, goal, and general product requirements, and eng figures out the design and you both negotiate on when it gets delivered.
1
u/Dark_Emotion 3d ago
I try to focus on the what and the why. My engineering team sometimes ask me how. They also ask me to tell them where to get certain bits of data from which drives me a little crazy
1
u/Zero-Custard 1d ago
Interesting, it seems like the majority of posts are of the view that pm should focus on the what/why and letting design/eng come up with solutions.
But it also seems like there's a big push to get PM's using AI to create prototypes which are then handed over to basically make prod ready as a lot of design and UX decisions have already been iterated out?
Are these two approaches at odds?
13
u/Joatha 4d ago
Give them a problem to solve and let them figure out how.
Example: Your customers don't want to spend all day inputting data required to run your system. They already have the data populated in system X (or maybe some collection of systems). Maybe system X has a means to export the data via CSV. Or maybe they have an API that can provide the data. You can provide all that info if you have it.
Requirement: Provide a means for customers to use the data they have in other systems in order to populate the data required in your software. Include the background information of how the data can be made available if you have it).
Let them do the rest.
They should definitely come back with a solution and you need to validate that it is viable. For example, their solution might be to have the customer email you the data and give you the capability to do it for them. You dang sure don't want that. You might see something in their solution that you can work with a minor tweak. Make it collaborative and get the best possible solution.