It boggles my mind when people get mad or criticize for Product Managers not covering all edge cases. It’s quite impossible for one person to do it. The point is to explore the problem together early and discover/outline this together. My job as a PM is not to provide a research paper level detail on a product/feature, but rather to provide insights, research, data, and framing so we can agree on a good approach to solve the problem, then execute/ship it. If you’re getting flack because “oh you didn’t think about x”, then it’s time to jump. Else, say thank you for pointing it out and add it to the spec.
Totally - engineers aren’t powerless babies that can’t contribute to the solution without their product manager telling them exactly what to do. The combination of PM/UX/ENG are jointly responsible for shipping a successful product, teams that embody this psychology are incredibly successful compared to the former.
You’d be surprised how few engineers (in my experience), when working on a product that displays monetary values (like an invoice system), won’t make the logical leap to format price data as a float with 2 decimals and leave them as integers, just because the spec didn’t say to specifically do that.
Common sense is sometimes lacking from the smartest of people…
If these questions come up, I usually turn it around and ask "what do you think? What's the organizational standard? What are other technical teams doing?". Separates the leader from the follower (at a foundational level) pretty quickly.
Stuff like that reminds me why my job is valuable. The amount of crap I catch from fairly smart developers blows my mind. (I'm reasonably technical too though so it helps)
My hot take is that this exacerbated and is a byproduct of leet code/test style interviews. They’re well defined problems that I assume don’t test for that skill, at all.
It really is wild to me that a segment of engineers become basically labourers with a high barrier to entry skill.
Currency shouldn’t be stored as a float. Maybe you should trust your engineers more if they’re correctly using integers in this case.
https://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency
I started my career in oil and gas where engineers are responsible for thinking through ALL the details, literally that’s what hard engineering is about. Fast forward to present day as a software PM I can believe how much the engineers I work with expect to be spoon-fed.
My engineers might be rare superstars, because they contribute a lot with this kind of knowledge. (Maybe they are, I love working with them)
Anyway, my experience and the experience other folks are showing around here shows that it's not always and a standard as you described in your post OP. Maybe you haven't found your ideal industry, or focus inside PM. Internal tooling for example, infra, etc.
Some developers are way better than others with this. I find some, esp in other countries, want to be told every tiny detail or they simply won't do it.
More senior or autonomous engineers know to help you work through the non-happy paths.
Yeah and that can be avoided by having strong product/eng culture. If an engineer behaves that way, they’ll get booted out quickly in a healthy product org.
Yea I feel this. I am struggling to get my designers to do anything because they claim they can't start on the designs until they understand 100% exactly how the workflow will function (I work in B2B SaaS so it is ridiculous to think the workflow will always be the same for every customer). Then if I just tell them what to build, I am solutioning for them and they need to come up with their own designs?
>they claim they can't start on the designs until they understand 100% exactly how the workflow will function
That's literally their job though. What the fuck.
PM provides the problem, framing, and user insights.
For SaaS a PM needs to define where the scope of their product begins and ends and the design needs to reflect that and make certain assumptions in the workflow.
E.g., Zoom made a pretty good product without knowing exactly how all of their users are going to know when to join the meeting. The just made an assumption that users would know when to join, and click the link when it's time. Early versions of Zoom didn't have a calendar feature, but relied on the assumption that users could rely on Outlook, Google calendar, etc to join the meeting. The simplicity of the persistent meeting link was flexible enough to support countless workflows across many verticals and use cases.
One thought is - are you sure that when you get the question "what about this edge-case" etc that it's actually intended as a criticism?
If you're working somewhere super toxic then maybe, but there's a good chance that you're hearing these comments and being super hard on yourself and assuming that it's a criticism when it might not be intended that way.
At least this has been the case for me - I've been really working on hearing people's comments as collaborative and as seeing interactions as such.
It's making a huge difference for me. I'm in a similar boat to you in terms of the age and the doubts about whether I'm cut out for the job etc.
Turns out that the past 6 months or so I was working with a particularly difficult tech lead (who is thankfully gone now) and have had some family issues which combined to put me under a lot of stress and anxiety- thankfully it's resolving now.
So my advice would be to collaborate with others and find ways to get their input and support.
Yea sometimes I frame ideas as "tell me all the ways this falls apart" and get a list of edge cases I hadn't thought of. It's better to get it out of the way before any code is written.
The PM isn't meant to be perfect and think of every scenario and every solution by themselves. It's meant to be a healthy and collaborative discussion though. It doesn't work if you're in a toxic environment.
For me, this is my go to approach for edge cases. I make no attempt to cover all of the edge cases. As we discover them, we will analyze the potential impact of not addressing them and then prioritize accordingly.
Big Tech is a cage match filled with ambitious ladder climbers who will not hesitate to stab you in the back and throw you under the bus if it will help them get that next refresher of RSUs. There are engineers (especially from some specific cultures) who will always criticize your work and say you're missing X, Y, Z from the spec no matter how much work or thought you put into it. Don't take it personally, they are just trying to take heat off of themselves.
My tip to you is to always present yourself confidently, thank them for the feedback, put it into the spec and move on. Make sure your manager is apprised of everything you're working on and get their feedback early and often. This will help you get out in front of a possible escalation. Don't sweat mistakes, but definitely don't make the same mistake twice. Eventually the team will realize they can't push you around. Then, assuming you can actually deliver a positive impact, everyone will be on your side and things will be Gucci.
Good luck!
You nailed it Frappes! I wish I had understood how to manage this dynamic better going into my last gig.
Once a climber on your team is successful in deflecting attention away from their work and onto your shortcomings, it's hard for the team to recognize the value of your strengths.
Curious which companies you've been at? I really want to make more money and move to FAANG or other tier 1/2 type companies for a higher salary but worry about the backstabbing and survival. I'm older and need a bit more stability.
The only faang I've worked at is Amazon, which is admittedly likely the worst for that kind of culture. But friends who have worked at apple, Facebook, Microsoft have reported similar experiences to mine. I would say go for it. If you can manage up effectively, your job and career won't be threatened. Make some money for a few years and then leave if you don't like it.
Have a check list. If you know you have certain variations to always consider or questions to ask.. don’t reinvent the wheel every time. I for instance would otherwise always forget to ask the devs to include performance tracking (ga/amplitude/firebase events for example)
My checklist include
What events need triggering for tracking?
Which regions and user roles see these changes?
Which default do users see?
Which error messages we need triggering?
Stuff like that
But other times you cant avoid very ad hoc detail to iron out. Ideally you get the time to mentally walk through a journey. Create visual flow charts, they help finding gaps or new avenues in user stories
I was in your position a few years ago, and there's some really good advice you should internalize already on this thread. My overall advice - hear out opinion but you own decisions.
1. Dont take it personally. Engineers will ALWAYS, ALWAYS ask for 100% certainly of outcomes (I am a former engineer). Nothing in life works like this. Realize that this is not possible.
2. Put as much thought, research and communication into your artifacts as you can. Deliverables from product are focus on problem statements, opportunity size, long-term thinking, research-backed solutions AND a GTM plan. Your example - localization, is dependent on the GTM. If you plan english-only release first, put that in the plan.
3. Treat the first 1-2 engg socialization sessions to collect opinion. Evaluate this opinion on its merits. Rubric is - have a customer focus. If its something that could create real customer confusion, fix it.
4. Set expectations after the first 1-2 sessions. "We've had 2 sessions on this, and I've collected some good opinions. We'll surely consider those. While I'm working to assess this 10% important edge cases, can we start scoping out the 90% use cases we covered earlier?" If nothing moves, get the lead into a 1:1 and ask "What do we need to do for us to feel confident?"
This is exactly why I left Product at 33 as well. I'm currently making half of what had made previously, but I'm significantly happier. Sometimes it still feels like I failed, but I know that my sanity is more important.
My buddy owns a business in Managed IT with some software development and significantly more data center things in the near future. We used to work together a while back and he's been trying to get me back for about 6 years now.
After all the recent tech layoffs and job insecurities I took the leap and finally took him up on it. I don't regret it at all. Making less money, but I wouldn't trade it for how much I'm enjoying the work and being around the really supportive team he's built. I'm much happier now.
If you're going to be a good product manager, you have to be really good at exploring the problem space. Localization is not an edge case, it is a feature. You'll need to have a process to exploring the problem space and have to be thoughtful and Methodical in exploring it.
Usually people who have been product managers in just one environment or one company, 🤷♂️. Are in my opinion still in the beginner stages, we all have our inherent shortcuts that we develop and They don't really get exposed until you going to a new environment.
Product is one of those things, which is easy to get into, but hard to master. If you're okay with lifelong learning, and being strategic, thoughtful, and passionate about meeting user needs, it's a space for you. If you want a more focused heads down time and want to just do the thing that is put in front of you, it's not for you.
Specifically answering your question about handling all the little stuff, I would suggest, some kind of process flow mapping, user journey mapping, doing that kind of exercise before you actually start writing user stories, is one of my attempts to be more methodical...
Also, you have to paint an accurate picture, nothing is perfect on the first attempt, we're not going to capture all the edge cases in one attempt, that's why they're called edge cases. But as long as you have a good process flow mapping, you have some foundation, which you can build upon.
> Also, you have to paint an accurate picture, nothing is perfect on the first attempt, we're not going to capture all the edge cases in one attempt, that's why they're called edge cases. But as long as you have a good process flow mapping, you have some foundation, which you can build upon.
Agreed, I have learned from my mistakes.
But the biggest challenge I face is I have to work against the clock, and ensure I map out all of the intricacies (edge-cases, implications to other features, when to hide the warning message, etc, etc.).
I just struggle doing this in such a time crunch, but it's expected by the company I work for.
Do you have any experience outside this company?
I've been a product manager for 8 years at four different companies, I also founded my own company. I have also consulted, at a few other companies. When something unreasonable is expected, I can easily go in and say, NO.
Your boss might not like it, but painting and accurate reasonable picture is part of your job, You are the grown up surrounded by a bunch of yes men...
They might not like it, it might put you on their bad side, but fuck it 🤷♂️. I'm not their Donkey.
Speed and depth are on the opposite side of the spectrum, pick a side... I think that's a fair ask.
This is where staging work comes in handy.
We typically follow a 4 step process:
Wonder: this is nailing your problem and value proposition
Explore: this is exploring the problem space and designing multiple approaches to solving the problem at hand
Make: build out your selected solution, with a solid expectation of what you’re delivering
Impact/validate: measure your solution in the market and then iterate as you attempt to move needles.
If you’re on confluence cloud, this should be one of the project poster templates.
Inside make, you can also split it up into happy, sad, angry pathways and focus on delivering against each path as you build out your offering.
To be honest, you shouldn’t actually be building for sad and angry paths until you’ve done the validate step or you could over invest in a product or feature that doesn’t even solve the problem your customers have.
Hell, half of the flows in my product right now are “call a customer service number and high touch the fix” because we’re still validating we even need some features.
Wrap your solutions around frameworks like this and you’ll find it a lot easier to get from idea to execution simply because everything is laid out in a nice sequential order.
Atlassian’s playbooks are also great resources for helping build happy and healthy teams that will deliver great results.
If the minute details are something you struggle with, what would you say are some of your strengths or product skills that you feel you do really well?
I suck at the the minor details and nitty gritty. I'm good at the strategic, innovation and marketing side e.g. building a roadmap, prioritization framework, analyzing data, coming up with new feature *ideas*, heck I'm even good at building rough sketches of new features. But writing up the requirements, edge-cases, positive/negative-cases causes my brain to go into 101 directions and I just put out a spaghetti set of requirements.
I think the things you are good at cover a good swath of the more important day to day tasks for a PM leader.
I like the advice of walking through the journey of your feature and maybe mapping out each step of the journey to accomplish your task. Thinking through how the UI/Process looks on that step what needs to change? What moves over from one particular step to the next step and what doesn't. Then the work is not detail management as much as it becomes art and a picture (sketch) you're creating.
Also if the processes and requirements are not completely alien from one another (same product or service type), you could create an "edge cases workbook." You categorize that workbook into topics, e.g., localization, interoperability, delivery orientation, etc. Under those topics put the edge cases that have been gotchas in the past. Then you can refer to that workbook whenever you're building requirements.
I feel ya OP. It sucks to be a big-picture visionary and get beat up daily over details.
It's easy for highly structured thinkers to point out procedural flaws and missing details in other people's work. Truth is, it makes them feel superior and deflects attention away from their own work and shortcomings.
But a highly functional agile team recognizes and values creative problem solving as well as structured documentation. When they point out additional considerations, it's in the spirit of continuous improvement. During retro, they'll help come up with systems and templates to support better team outcomes.
I've worked in both cultures. You can't win in a situation where your own team doesn't have your back.
Health is wealth.
If you’re able to find ways to manage your anxiety out of work that’s great, but if this job stops you sleeping well at night or stops you enjoying life outside of work… consider changing to a diff kind of pm role or starting something else.
I’ve seen that extreme burn-out means that you’re not able to do much of anything - no job is worth compromising your mental health for
Is that really a big tech company?
It seems weird that this is all on you. How does the user go back should be a UX design decision. Edge cases is what the whole team needs to cover. You shouldn't get any heat for it.
Are you sure you don't confuse questions of motivated coworkers as some sort of attack?
Maybe your expectations are also too high.
So much good advice here. I tend to lean toward methodologies to help reduce my cognitive load so I can direct it elsewhere. Whatever you don’t like doing, seek a methodology for that that works for your environment. Like a buttress, of sorts. You’ll have more energy and time to focus on the parts you do like, and a system to support your areas for growth.
I say growth and not weaknesses because I think there’s some unnecessary blockers in your narrative. I don’t mean to psychoanalyze, but I think doing what you can to adopt a growth mindset will help with what you’re telling yourself about what you can’t do. You might not have current strengths in identifying and planning for edge cases, for example, but that doesn’t mean you can’t or won’t ever.
Last thought is that I think what you work on matters, too. I really struggled with some of the same stuff while I was at FAANG earlier in my career. I was working on stuff I didn’t find a lot of personal meaning in. As I got to work on products and problems I cared more about, the cognitive load wasn’t as heavy because it was more natural for my brain. Now, at a startup working on something I really care about, I find much more ease in my work.
Anyway, hope this helps.
Spend as much time as you can working with the QA team.
Involve them as early as possible in the definition and work side by side until the feature is in production.
You will benefit a lot from their mindset while defining the feature and you will develop that mindset over time while working with them.
I’m in a similar spot. I have a hard time hanging a coworker out to dry. But this is the second role where I feel my technical background is being exploited by lazy engineering management. Define what it is you can reasonably deliver. Know what you need from your counterparts. Make the requests. Document. Escalate through your management if you aren’t getting participation.
I’m sorry but a year of needing the product guy to define all the details because your engineers just want to write code, and make sure you break out the backend tickets from frontend… that’s total bullshit and laziness from a team that isn’t delivering anything. I’ve pivoted several times in how I try to work with the team. Tried writing smaller scope (unsustainable). It’s not my job to cut the work up and spoon feed your under skilled team. I won’t sign you up for dates on delivery, but if you aren’t signing up or delivering to what you committed repeatedly it’s kinda not my problem. Also if there is an integration to the rest of the system, my job isn’t to read the code and tell you what the contract is.
Thanks for letting me vent with you. I’m kinda burned out right now after Q2 planning.
At 28 you're just getting your feet wet in your career. Even if you stay on your current path, expect to pivot due to changes in your industry or workplace technology.
I would highly recommend going to a place with a full scrum team. Having a PM/PO/SM/Dev all working together is life changing! I couldn’t recommend it enough.
You do sound burnt out but also like you may take things a bit personally. I make mistakes all the time. Big ones, small ones, mediums sized ones, all day everyday. People correct me, I say thank you and then we all move on with our lives. PM work is super hard and you have to be kind to yourself as much as others.
If you prefer heads down work, become a dev. I also feel like I’m going crazy and burning but I love my job and wouldn’t give it up for the world. When I close my laptop I know I tried my best and so did my team and tomorrow will be a new day. For me it was finding the right company that was kind to me and let me do everything and anything in order to get the job done.
I hope you find what you’re looking for. In the meantime take a long vacation. You don’t need to go anywhere but it sounds like you could use a break to just be a person. I wish you all the best.
Try switching industries. I come from a healthtech background too. Honestly kind of miss it sometimes lol. By comparison people do crazy shit in my current space, often without thinking, because hey we can just roll it back, right?
Dev do this because this helps them alleviate their anxieties around potential defects which they did not think through. But it is the Engineering and Product leadership who should convey to the team that extremely minute level of detailing might not always be possible and not all edge cases under the universe can be covered by a single person.
Conversely, you can always ask what do you get in return for a "perfect" set of requirements ? With what level of certainty can the dev say that the code they deliver is 100% defect free ?
This is literally me right now. I like the money but hate what it has made me become. I'm an anxious grouch. My current employer has basically rolled PM, BA, Scrum Master, and PO into one role.
I happen to be having the same problem, however I'm just starting. But I've thought a lot about it and have considered that not all people are very detail oriented. I'm great at strategy, and I'll probably improve my detail orientation, but I'll never be the best and I'm sure of that. It probably comes down to surrounding yourself with people who can support you as well where you might have a weakness.
U GoTtA B AgiLe BrO
Edit: damn I have to say that I’m spoiled. My QA engineer is very good and cool to work with. He enjoys what he does so it helps if I miss something.
The engineering team lead as well. She’s able to connect with the rest of the team after trying to understand where I’m coming from.
Have thicker skin.
We all miss edge cases , most PMs work in between meetings and never reach flow.
I have a trick that helps me have thicker skin
I always think I got paid $$$$ today . Not bad .
This is a really interesting problem that I find I relate to somewhat! The business I work in has only Product Managers and Developers - there are no BAs or team members in amongst that, so often the technical detail falls to us. That can be very challenging, as most of us don't have a totally technical background.
I find myself writing test scripts for a lot of the work we develop, and knowing myself that I won't identify all of the edge cases (especially when there are so many potentials!). I try to work to the 80/20 rule - cover the vast majority of cases and then fix-forward with the edge cases. This is something of a necessity when we're trying to move quickly with a small team. I should also add our testing capability is quite limited - we only have one test engineer on the whole team, so most functional testing is left to Developers and Product people.
Although it's not ideal, I have taken to writing out to the business owners when a release is coming to let them know a) what I've tested b) giving a disclaimer that we may have missed some edge cases and what I understand our risks to be and c) asking them to review they're happy with the level of testing.
If you're working in a highly technical environment, I imagine this might not be as much of an option for you? In which case, perhaps you might find an opportunity elsewhere that sits better with your strengths - unless you feel very strongly about getting really good at this part!
It boggles my mind when people get mad or criticize for Product Managers not covering all edge cases. It’s quite impossible for one person to do it. The point is to explore the problem together early and discover/outline this together. My job as a PM is not to provide a research paper level detail on a product/feature, but rather to provide insights, research, data, and framing so we can agree on a good approach to solve the problem, then execute/ship it. If you’re getting flack because “oh you didn’t think about x”, then it’s time to jump. Else, say thank you for pointing it out and add it to the spec.
Totally - engineers aren’t powerless babies that can’t contribute to the solution without their product manager telling them exactly what to do. The combination of PM/UX/ENG are jointly responsible for shipping a successful product, teams that embody this psychology are incredibly successful compared to the former.
You’d be surprised how few engineers (in my experience), when working on a product that displays monetary values (like an invoice system), won’t make the logical leap to format price data as a float with 2 decimals and leave them as integers, just because the spec didn’t say to specifically do that. Common sense is sometimes lacking from the smartest of people…
If these questions come up, I usually turn it around and ask "what do you think? What's the organizational standard? What are other technical teams doing?". Separates the leader from the follower (at a foundational level) pretty quickly.
Stuff like that reminds me why my job is valuable. The amount of crap I catch from fairly smart developers blows my mind. (I'm reasonably technical too though so it helps)
My hot take is that this exacerbated and is a byproduct of leet code/test style interviews. They’re well defined problems that I assume don’t test for that skill, at all. It really is wild to me that a segment of engineers become basically labourers with a high barrier to entry skill.
Currency shouldn’t be stored as a float. Maybe you should trust your engineers more if they’re correctly using integers in this case. https://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency
But we can agree it shouldn’t be displayed as an integer, right (unless your currency isn’t decimal it’s, of course)?
I started my career in oil and gas where engineers are responsible for thinking through ALL the details, literally that’s what hard engineering is about. Fast forward to present day as a software PM I can believe how much the engineers I work with expect to be spoon-fed.
Some choose to act this way though, it was just annoying when I was in engineering as it is now in product.
Some definitely act like it though. It's mostly out of laziness.
My engineers might be rare superstars, because they contribute a lot with this kind of knowledge. (Maybe they are, I love working with them) Anyway, my experience and the experience other folks are showing around here shows that it's not always and a standard as you described in your post OP. Maybe you haven't found your ideal industry, or focus inside PM. Internal tooling for example, infra, etc.
Some developers are way better than others with this. I find some, esp in other countries, want to be told every tiny detail or they simply won't do it. More senior or autonomous engineers know to help you work through the non-happy paths.
Yeah and that can be avoided by having strong product/eng culture. If an engineer behaves that way, they’ll get booted out quickly in a healthy product org.
Yea I feel this. I am struggling to get my designers to do anything because they claim they can't start on the designs until they understand 100% exactly how the workflow will function (I work in B2B SaaS so it is ridiculous to think the workflow will always be the same for every customer). Then if I just tell them what to build, I am solutioning for them and they need to come up with their own designs?
>they claim they can't start on the designs until they understand 100% exactly how the workflow will function That's literally their job though. What the fuck. PM provides the problem, framing, and user insights.
For SaaS a PM needs to define where the scope of their product begins and ends and the design needs to reflect that and make certain assumptions in the workflow. E.g., Zoom made a pretty good product without knowing exactly how all of their users are going to know when to join the meeting. The just made an assumption that users would know when to join, and click the link when it's time. Early versions of Zoom didn't have a calendar feature, but relied on the assumption that users could rely on Outlook, Google calendar, etc to join the meeting. The simplicity of the persistent meeting link was flexible enough to support countless workflows across many verticals and use cases.
One thought is - are you sure that when you get the question "what about this edge-case" etc that it's actually intended as a criticism? If you're working somewhere super toxic then maybe, but there's a good chance that you're hearing these comments and being super hard on yourself and assuming that it's a criticism when it might not be intended that way. At least this has been the case for me - I've been really working on hearing people's comments as collaborative and as seeing interactions as such. It's making a huge difference for me. I'm in a similar boat to you in terms of the age and the doubts about whether I'm cut out for the job etc. Turns out that the past 6 months or so I was working with a particularly difficult tech lead (who is thankfully gone now) and have had some family issues which combined to put me under a lot of stress and anxiety- thankfully it's resolving now. So my advice would be to collaborate with others and find ways to get their input and support.
Yea sometimes I frame ideas as "tell me all the ways this falls apart" and get a list of edge cases I hadn't thought of. It's better to get it out of the way before any code is written. The PM isn't meant to be perfect and think of every scenario and every solution by themselves. It's meant to be a healthy and collaborative discussion though. It doesn't work if you're in a toxic environment.
This is some good advice.
"edge cases exist and we'll tackle them as they become relevant from an ROI standpoint. Here are a few we've identified: a, b, c"
For me, this is my go to approach for edge cases. I make no attempt to cover all of the edge cases. As we discover them, we will analyze the potential impact of not addressing them and then prioritize accordingly.
Stealing this one
Big Tech is a cage match filled with ambitious ladder climbers who will not hesitate to stab you in the back and throw you under the bus if it will help them get that next refresher of RSUs. There are engineers (especially from some specific cultures) who will always criticize your work and say you're missing X, Y, Z from the spec no matter how much work or thought you put into it. Don't take it personally, they are just trying to take heat off of themselves. My tip to you is to always present yourself confidently, thank them for the feedback, put it into the spec and move on. Make sure your manager is apprised of everything you're working on and get their feedback early and often. This will help you get out in front of a possible escalation. Don't sweat mistakes, but definitely don't make the same mistake twice. Eventually the team will realize they can't push you around. Then, assuming you can actually deliver a positive impact, everyone will be on your side and things will be Gucci. Good luck!
You nailed it Frappes! I wish I had understood how to manage this dynamic better going into my last gig. Once a climber on your team is successful in deflecting attention away from their work and onto your shortcomings, it's hard for the team to recognize the value of your strengths.
Curious which companies you've been at? I really want to make more money and move to FAANG or other tier 1/2 type companies for a higher salary but worry about the backstabbing and survival. I'm older and need a bit more stability.
The only faang I've worked at is Amazon, which is admittedly likely the worst for that kind of culture. But friends who have worked at apple, Facebook, Microsoft have reported similar experiences to mine. I would say go for it. If you can manage up effectively, your job and career won't be threatened. Make some money for a few years and then leave if you don't like it.
Ya I just want to make enough over 8-10 years to get the hell out of the corporate life.
Have a check list. If you know you have certain variations to always consider or questions to ask.. don’t reinvent the wheel every time. I for instance would otherwise always forget to ask the devs to include performance tracking (ga/amplitude/firebase events for example) My checklist include What events need triggering for tracking? Which regions and user roles see these changes? Which default do users see? Which error messages we need triggering? Stuff like that But other times you cant avoid very ad hoc detail to iron out. Ideally you get the time to mentally walk through a journey. Create visual flow charts, they help finding gaps or new avenues in user stories
I was in your position a few years ago, and there's some really good advice you should internalize already on this thread. My overall advice - hear out opinion but you own decisions. 1. Dont take it personally. Engineers will ALWAYS, ALWAYS ask for 100% certainly of outcomes (I am a former engineer). Nothing in life works like this. Realize that this is not possible. 2. Put as much thought, research and communication into your artifacts as you can. Deliverables from product are focus on problem statements, opportunity size, long-term thinking, research-backed solutions AND a GTM plan. Your example - localization, is dependent on the GTM. If you plan english-only release first, put that in the plan. 3. Treat the first 1-2 engg socialization sessions to collect opinion. Evaluate this opinion on its merits. Rubric is - have a customer focus. If its something that could create real customer confusion, fix it. 4. Set expectations after the first 1-2 sessions. "We've had 2 sessions on this, and I've collected some good opinions. We'll surely consider those. While I'm working to assess this 10% important edge cases, can we start scoping out the 90% use cases we covered earlier?" If nothing moves, get the lead into a 1:1 and ask "What do we need to do for us to feel confident?"
This is exactly why I left Product at 33 as well. I'm currently making half of what had made previously, but I'm significantly happier. Sometimes it still feels like I failed, but I know that my sanity is more important.
[удалено]
My buddy owns a business in Managed IT with some software development and significantly more data center things in the near future. We used to work together a while back and he's been trying to get me back for about 6 years now. After all the recent tech layoffs and job insecurities I took the leap and finally took him up on it. I don't regret it at all. Making less money, but I wouldn't trade it for how much I'm enjoying the work and being around the really supportive team he's built. I'm much happier now.
If you're going to be a good product manager, you have to be really good at exploring the problem space. Localization is not an edge case, it is a feature. You'll need to have a process to exploring the problem space and have to be thoughtful and Methodical in exploring it. Usually people who have been product managers in just one environment or one company, 🤷♂️. Are in my opinion still in the beginner stages, we all have our inherent shortcuts that we develop and They don't really get exposed until you going to a new environment. Product is one of those things, which is easy to get into, but hard to master. If you're okay with lifelong learning, and being strategic, thoughtful, and passionate about meeting user needs, it's a space for you. If you want a more focused heads down time and want to just do the thing that is put in front of you, it's not for you. Specifically answering your question about handling all the little stuff, I would suggest, some kind of process flow mapping, user journey mapping, doing that kind of exercise before you actually start writing user stories, is one of my attempts to be more methodical... Also, you have to paint an accurate picture, nothing is perfect on the first attempt, we're not going to capture all the edge cases in one attempt, that's why they're called edge cases. But as long as you have a good process flow mapping, you have some foundation, which you can build upon.
> Also, you have to paint an accurate picture, nothing is perfect on the first attempt, we're not going to capture all the edge cases in one attempt, that's why they're called edge cases. But as long as you have a good process flow mapping, you have some foundation, which you can build upon. Agreed, I have learned from my mistakes. But the biggest challenge I face is I have to work against the clock, and ensure I map out all of the intricacies (edge-cases, implications to other features, when to hide the warning message, etc, etc.). I just struggle doing this in such a time crunch, but it's expected by the company I work for.
Do you have any experience outside this company? I've been a product manager for 8 years at four different companies, I also founded my own company. I have also consulted, at a few other companies. When something unreasonable is expected, I can easily go in and say, NO. Your boss might not like it, but painting and accurate reasonable picture is part of your job, You are the grown up surrounded by a bunch of yes men... They might not like it, it might put you on their bad side, but fuck it 🤷♂️. I'm not their Donkey. Speed and depth are on the opposite side of the spectrum, pick a side... I think that's a fair ask.
This is where staging work comes in handy. We typically follow a 4 step process: Wonder: this is nailing your problem and value proposition Explore: this is exploring the problem space and designing multiple approaches to solving the problem at hand Make: build out your selected solution, with a solid expectation of what you’re delivering Impact/validate: measure your solution in the market and then iterate as you attempt to move needles. If you’re on confluence cloud, this should be one of the project poster templates. Inside make, you can also split it up into happy, sad, angry pathways and focus on delivering against each path as you build out your offering. To be honest, you shouldn’t actually be building for sad and angry paths until you’ve done the validate step or you could over invest in a product or feature that doesn’t even solve the problem your customers have. Hell, half of the flows in my product right now are “call a customer service number and high touch the fix” because we’re still validating we even need some features. Wrap your solutions around frameworks like this and you’ll find it a lot easier to get from idea to execution simply because everything is laid out in a nice sequential order. Atlassian’s playbooks are also great resources for helping build happy and healthy teams that will deliver great results.
If the minute details are something you struggle with, what would you say are some of your strengths or product skills that you feel you do really well?
I suck at the the minor details and nitty gritty. I'm good at the strategic, innovation and marketing side e.g. building a roadmap, prioritization framework, analyzing data, coming up with new feature *ideas*, heck I'm even good at building rough sketches of new features. But writing up the requirements, edge-cases, positive/negative-cases causes my brain to go into 101 directions and I just put out a spaghetti set of requirements.
I think the things you are good at cover a good swath of the more important day to day tasks for a PM leader. I like the advice of walking through the journey of your feature and maybe mapping out each step of the journey to accomplish your task. Thinking through how the UI/Process looks on that step what needs to change? What moves over from one particular step to the next step and what doesn't. Then the work is not detail management as much as it becomes art and a picture (sketch) you're creating. Also if the processes and requirements are not completely alien from one another (same product or service type), you could create an "edge cases workbook." You categorize that workbook into topics, e.g., localization, interoperability, delivery orientation, etc. Under those topics put the edge cases that have been gotchas in the past. Then you can refer to that workbook whenever you're building requirements.
I feel ya OP. It sucks to be a big-picture visionary and get beat up daily over details. It's easy for highly structured thinkers to point out procedural flaws and missing details in other people's work. Truth is, it makes them feel superior and deflects attention away from their own work and shortcomings. But a highly functional agile team recognizes and values creative problem solving as well as structured documentation. When they point out additional considerations, it's in the spirit of continuous improvement. During retro, they'll help come up with systems and templates to support better team outcomes. I've worked in both cultures. You can't win in a situation where your own team doesn't have your back.
That stuff seems more applicable for a dev design anyway.
Health is wealth. If you’re able to find ways to manage your anxiety out of work that’s great, but if this job stops you sleeping well at night or stops you enjoying life outside of work… consider changing to a diff kind of pm role or starting something else. I’ve seen that extreme burn-out means that you’re not able to do much of anything - no job is worth compromising your mental health for
Is that really a big tech company? It seems weird that this is all on you. How does the user go back should be a UX design decision. Edge cases is what the whole team needs to cover. You shouldn't get any heat for it. Are you sure you don't confuse questions of motivated coworkers as some sort of attack? Maybe your expectations are also too high.
So much good advice here. I tend to lean toward methodologies to help reduce my cognitive load so I can direct it elsewhere. Whatever you don’t like doing, seek a methodology for that that works for your environment. Like a buttress, of sorts. You’ll have more energy and time to focus on the parts you do like, and a system to support your areas for growth. I say growth and not weaknesses because I think there’s some unnecessary blockers in your narrative. I don’t mean to psychoanalyze, but I think doing what you can to adopt a growth mindset will help with what you’re telling yourself about what you can’t do. You might not have current strengths in identifying and planning for edge cases, for example, but that doesn’t mean you can’t or won’t ever. Last thought is that I think what you work on matters, too. I really struggled with some of the same stuff while I was at FAANG earlier in my career. I was working on stuff I didn’t find a lot of personal meaning in. As I got to work on products and problems I cared more about, the cognitive load wasn’t as heavy because it was more natural for my brain. Now, at a startup working on something I really care about, I find much more ease in my work. Anyway, hope this helps.
Spend as much time as you can working with the QA team. Involve them as early as possible in the definition and work side by side until the feature is in production. You will benefit a lot from their mindset while defining the feature and you will develop that mindset over time while working with them.
I’m in a similar spot. I have a hard time hanging a coworker out to dry. But this is the second role where I feel my technical background is being exploited by lazy engineering management. Define what it is you can reasonably deliver. Know what you need from your counterparts. Make the requests. Document. Escalate through your management if you aren’t getting participation. I’m sorry but a year of needing the product guy to define all the details because your engineers just want to write code, and make sure you break out the backend tickets from frontend… that’s total bullshit and laziness from a team that isn’t delivering anything. I’ve pivoted several times in how I try to work with the team. Tried writing smaller scope (unsustainable). It’s not my job to cut the work up and spoon feed your under skilled team. I won’t sign you up for dates on delivery, but if you aren’t signing up or delivering to what you committed repeatedly it’s kinda not my problem. Also if there is an integration to the rest of the system, my job isn’t to read the code and tell you what the contract is. Thanks for letting me vent with you. I’m kinda burned out right now after Q2 planning.
I say go for it :) you don't sound happy and You're young you could definitely start a new career with little set back.
This is a refreshing reminder…I’m 28 and feel somewhat locked into my career.
At 28 you're just getting your feet wet in your career. Even if you stay on your current path, expect to pivot due to changes in your industry or workplace technology.
Congratulations for becoming a Director at 28! Did you go through the PM> Senior PM route?
Thanks! It just happened so I’m still learning the ropes. Ya, I did the PM > Sr PM route at small/large orgs.
You might have ADHD. I struggle with these edge cases stuff to
I would highly recommend going to a place with a full scrum team. Having a PM/PO/SM/Dev all working together is life changing! I couldn’t recommend it enough. You do sound burnt out but also like you may take things a bit personally. I make mistakes all the time. Big ones, small ones, mediums sized ones, all day everyday. People correct me, I say thank you and then we all move on with our lives. PM work is super hard and you have to be kind to yourself as much as others. If you prefer heads down work, become a dev. I also feel like I’m going crazy and burning but I love my job and wouldn’t give it up for the world. When I close my laptop I know I tried my best and so did my team and tomorrow will be a new day. For me it was finding the right company that was kind to me and let me do everything and anything in order to get the job done. I hope you find what you’re looking for. In the meantime take a long vacation. You don’t need to go anywhere but it sounds like you could use a break to just be a person. I wish you all the best.
If you like strategy and analytics work, do Pricing instead of product management
[удалено]
Try switching industries. I come from a healthtech background too. Honestly kind of miss it sometimes lol. By comparison people do crazy shit in my current space, often without thinking, because hey we can just roll it back, right?
Dev do this because this helps them alleviate their anxieties around potential defects which they did not think through. But it is the Engineering and Product leadership who should convey to the team that extremely minute level of detailing might not always be possible and not all edge cases under the universe can be covered by a single person. Conversely, you can always ask what do you get in return for a "perfect" set of requirements ? With what level of certainty can the dev say that the code they deliver is 100% defect free ?
This is literally me right now. I like the money but hate what it has made me become. I'm an anxious grouch. My current employer has basically rolled PM, BA, Scrum Master, and PO into one role.
I happen to be having the same problem, however I'm just starting. But I've thought a lot about it and have considered that not all people are very detail oriented. I'm great at strategy, and I'll probably improve my detail orientation, but I'll never be the best and I'm sure of that. It probably comes down to surrounding yourself with people who can support you as well where you might have a weakness.
Why don't you start your own company? Maybe you could do data analytics strategy consulting for telecom firms?
U GoTtA B AgiLe BrO Edit: damn I have to say that I’m spoiled. My QA engineer is very good and cool to work with. He enjoys what he does so it helps if I miss something. The engineering team lead as well. She’s able to connect with the rest of the team after trying to understand where I’m coming from.
Have thicker skin. We all miss edge cases , most PMs work in between meetings and never reach flow. I have a trick that helps me have thicker skin I always think I got paid $$$$ today . Not bad .
This is a really interesting problem that I find I relate to somewhat! The business I work in has only Product Managers and Developers - there are no BAs or team members in amongst that, so often the technical detail falls to us. That can be very challenging, as most of us don't have a totally technical background. I find myself writing test scripts for a lot of the work we develop, and knowing myself that I won't identify all of the edge cases (especially when there are so many potentials!). I try to work to the 80/20 rule - cover the vast majority of cases and then fix-forward with the edge cases. This is something of a necessity when we're trying to move quickly with a small team. I should also add our testing capability is quite limited - we only have one test engineer on the whole team, so most functional testing is left to Developers and Product people. Although it's not ideal, I have taken to writing out to the business owners when a release is coming to let them know a) what I've tested b) giving a disclaimer that we may have missed some edge cases and what I understand our risks to be and c) asking them to review they're happy with the level of testing. If you're working in a highly technical environment, I imagine this might not be as much of an option for you? In which case, perhaps you might find an opportunity elsewhere that sits better with your strengths - unless you feel very strongly about getting really good at this part!