7 ms·

There are many kinds of "negative" responses: 0. This idea is bad. 1. This idea is probably bad, but if someone wants to put together a more compelling argume

There are many kinds of "negative" responses: 0. This idea is bad. 1. This idea is probably bad, but if someone wants to put together a more compelling argument we will discuss it at a future meeting. 2. This idea needs to be more fully developed before we can decide whether it is good or bad. 3. This idea is probably good, but it will remain in backlog limbo until someone makes a compelling argument that it is a priority. 4. This idea is good, and while it is not a high-enough priority to displace our current tasks, we will actively discuss including it when we plan our next sprint/release. Depending on who you work with these may need to be gussied up with manager-speak to let people save face or to prevent people from hijacking the agenda to turn the meeting into a brainstorming session. But treating all of them as synonymous with "no" loses useful nuance.

ryandrake 2y ago
In most companies I've worked, in order to actually implement an idea, you need to prove a few things, whether the person proposing it is the PM, an engineer, or any other person involved in the product: 1. The idea is technically feasible 2. The idea aligns with company's business goals 3. The idea is our team's responsibility and cannot be done by another team 4. The idea is more important than the other things our team plans to work on in the future 5. The idea is more time critical than the other things our team is working on now If any of these cannot be proven, then it goes on the backlog as a P4 and nobody realistically will ever look at it. It's just the reality of corporate software building. There are always 10-50x more ideas than there are staff/time to work on. Of course, all five of those can be, and often are, overridden by the Prime Directive: 0. One of the executives (often one of your grand-bosses high up on the totem pole) wants it.
- p1necone 2y ago
  In my experience the more fine grained an organizations issue tracking/planning is the more this is a problem vs a reasonable process. If you have to convince someone of all of those things in order to build some reasonably large thing over the space of a few weeks, that's probably reasonable. If you have to convince someone of all of those things in order to allocate a few hours to fixing some tech debt or minor bug then your codebase is going to slowly deteriorate until the same someone is asking you why there's so many bugs and everything takes so long to develop.
  - elevatedastalt 2y ago
    Usually most engineers have some slack time and can pick things up to fix. The problem is not in them doing that. The issues arrises in one of two things— [1] They either use the fact that they are fixing that thing as an excuse to not work on or deliver on time a different, more important task. If that happens, obvious questions about prioritization occur. [2] They want a substantial amount of credit or recognition for doing it. Usually such fixes don't receive exec attention (since execs are tracking more important projects) and so don't get the same due as a properly tracked project does.
    - wbl 2y ago
      3: the fix is easy but the integration testing and deployment cannot happen without allocated time.
      - titusjohnson 2y ago
        In my experience this aspect is chronically underestimated by devs. The change needs testing. Change Management might need to create artifacts. Help articles might need updating. Certain clients may need a heads-up. All the PMs need to be briefed (this change is outside of their roadmap so it'll be a fun surprise). As an org grows the piece of the Effort Pie that is Development gets smaller and smaller. It's not that development gets easier, it's that every other part of the process grows in size and importance faster than the Development piece grows. It takes about an hour of developer time to incidentally produce 20 hours of work elsewhere in the company.
    - deleted 2y ago
      [deleted]
- Dylan16807 2y ago
  If it meets 1-4 does it get forgotten or does someone reliably come back to check for 5 becoming true?
  - joshuanapoli 2y ago
    Probably the person who came up with the idea remains the most invested in it, and they should to watch for number 5 “the right moment” to bring it up again.
- psunavy03 2y ago
  Or you work at a non-software company where the technical folks ultimately report to a non-technical boss, or are outnumbered by nontechnical executives. In which case, there's the real danger of a bunch of 0 getting shoved down your collective throat to the tune of "it's all a priority, get it done."
  - asoneth 2y ago
    > "it's all a priority, get it done." Reminds me of a product owner I had who abused priority categories by insisting that the majority of his tasks were "top priorities" because he had discovered that any time he didn't mark a task as a top priority it wouldn't get done. Every team ended up sorting his tasks as a flat list so that when he asked people to "make this a top priority" it was up to him to decide where it went in the list and which of his other requests would get bumped.
    - skydhash 2y ago
      That reminds me of a technique in the Slow Productivity book by Carl Newport. The gist is, if you cannot control the flow of work, the best thing to do is to create a buffer and make the workload visible. So they can visualize how any new task is going to disrupt it.
- dyarosla 2y ago
  Also, but rarely: Some engineer wants it bad enough that they just build it -or some version of it- and then some executive gives the go-ahead to invest more into it. At the end of the day, ideas are just ideas. Execution is everything.
  - 3vidence 2y ago
    I've learned the value of this. Some people don't realize the value of something unless you show it to them. It's a risk for sure but honestly it keeps me sane vs trying to get 10 people aligned before starting something and then running out of time. People will happily take credit for your work after it works.
    - unkulunkulu 2y ago
      yep, an engineer has the power to directly influence the code. This is a strong power. Sometimes just making a PR is enough and a good convincer in and of itself. Use sparingly of course, weigh in time for making the argument, but this is an artifact just as a convincing research, text or a plot. code can be part of the argument.
    - sfn42 2y ago
      I once worked on an application that integrated with a third party api. The way it did this was with a large and horrible client library that used a separate db to cache the data. The data was then fetched from the main application and used to rebuild the pages (in the main db) based on this data once a day. The library had lots of problems, and one day it stopped working. I was tasked with fixing it - we had the source code, it was purchased from someone and copied into the repo. I spent most of the week if not more trying to figure out what was wrong, but I couldn't. What I did learn was that this library was some of the worst most pointless code I'd ever seen. So I told the team that I think I can rebuild this thing from scratch faster than I can fix this bug. The intermediate db is pointless and most of the library code is dead, the rest is garbage. I can make a simple little thing that does exactly what we need better, faster and easier. Nope. No bueno, fix what we have. So I spent a few hours over the weekend, less than a workday, building the new solution. Come Monday I had it pretty much working, a few things needed to be done but it already supported the use case. The pages were built correctly, they had the necessary content but some things were a bit messed up, nothing difficult to fix. Showed it to the team, said I want to use this and delete the old stuff - nope. The only half-decent explanation I got was that the client had paid a way too high amount of money for this garbage library and I guess the team lead didn't want to tell them we wanted to throw it out or something like that.
- thaumasiotes 2y ago
  > 3. The idea is our team's responsibility and cannot be done by another team Is it really true that your company cannot implement any idea that could potentially be done by more than one team?
  - droopyEyelids 2y ago
    If more than one team could reasonably be the owner of something, -and- the ownership isn't going to get a manager promoted, there needs to be a showdown to see what team takes the impact to their roadmap
giancarlostoro 2y ago
"Add it to the backlog for review, we're not saying it'll be done, but it will at least be looked at an considered when we have bandwidth" Just be direct and realistic. If it's to a customer, "we'll add it to our backlog for review" and tag it as customer suggestion so it doesn't just sit there forever.
ghaff 2y ago
At a higher level, does the revenue it could result in be enough to move the needle and therefore be worth the attention up and down and across the management chain (to the degree it's a discrete program)?
- jillesvangurp 2y ago
  A good notion for value is that of option value. Not a lot of product managers understand this notion very well. Engineers tend to intuitively get this but they can't articulate it. You do work now to give you the option to do something later. Very simple really. PMs really don't get this. All this refactoring, over engineering, and whatever you want to call it. They'd prefer you to not do any of it. But of course engineers understand that those things can pay back later. Option value is a notion that Don Reinertsen promotes in his Lean 2.0 notion (google that and his name, mandatory stuff for wannabe PMs IMHO). Very simply put, he draws an analogy with stock options. They give you an option in the future to get some value. But there's a chance they'll be worthless and that you lose your money. The point is that the payoff can be much larger than the value loss. That's why they are popular tools for stock traders. There's a non linear relation loss-profit function. Which means you only need a few of your options to convert to profit to finance all of them. VC capital is based on this notion as well. Most startups are a write off. But a handful turn into unicorns and pay for the rest. In product management, option value is the notion that some idea might be worthless but could end up being worth a lot. Doing a lot of work on something that's just not worth a lot is probably wrong. Doing a little bit of work on something that might have a huge payoff is probably smart. Even if it's slightly risky or uncertain. Doing a lot of work on a lot of things that might be valuable like that at the cost of stuff that you actually should be doing is probably not optimal and very risky. But you should be taking some calculated risks at least part of the time just in case. Worst case you lose some time. Best case you create a lot of value in a way that you never planned to. Balancing risks is your job as a PM. The point here is that if you only do planned things and don't even entertain doing things that might be valuable outside of that scope, you are probably destroying a lot of value and you are placing a risky bet on your plan instead. If the plan is wrong, you might lose everything. Which is one of Reinertsen's key arguments against the original lean movement. You throw out the baby with the bath water if you do that. Bad idea for startups because you now make a risky bet on your plan being correct. Which of course it often isn't in startups. Pivoting is the notion of being able to turn a bad plan around. That gets easier if you invested in some option value that gives you the option to do so. A lot of unicorns emerged out of the ashes of failed startups. Big organizations are notorious for being risk averse and not having the internal capability to innovate even after they've identified the need to do so. As soon as management chains get involved, that's what happens.
cwbrandsma 2y ago
You forgot: Engineering is requesting this. So no.
jillesvangurp 2y ago
I like turning negatives into positives, as a way of providing constructive feedback. I'm doing product management on the side (I'm the CTO and also do a lot of the engineering) and the key issue I face is dealing with a large influx of good ideas and dealing with that in a way that minimizes my time having to evaluate things in our backlog. Saying no in a constructive way without pissing people off is key to being a good product manager. You need to be firm and decisive. But also very clear. The way I deal with this is several custom fields in our issue tracker kanban board that qualify any idea, no matter how good, crazy, in-feasible, etc. The most important ones are: - Value & Effort (one field) this is a quadrant of HighLow, HighHigh, LowLow, LowHigh. It's a reflection on what we would get out of doing something with the idea. High value and Low effort means you need a good reason not to kick an idea further. Low value and High effort kind of means a no, unless there's a really good reason. Anything in between can be decided on a case by case basis. I like the Low effort ones. They may not be that valuable. But sometimes they are nice to do. And you can just squeeze them in. - Next Step: This is a range of values that provide me an indication of when I should look at it again. Some things need to be fast tracked. Some things need more discussion/elaboration. And the rest is stuff that we might revisit or reject right now. I don't tend to spend time on rejected ideas unless somebody brings those to the table again. Things that linger too long without being actioned are going to end up labeled as rejected. Which just means they stop consuming my time. I have a few other fields (tags, priority, etc.) that are a bit more standard. But those two are the primary tools I use for deciding where to bucket ideas and how often to look at them. I should spend more time on high value ideas than on low value ones. And I should prioritize actioning items that have a next step that says I should do so. Anything else I can safely ignore indefinitely. If somebody doesn't agree, we can always discuss and change it. But there needs to be a good reason. This isn't perfect but it's a good mental model of dealing with incoming ideas in a bit structured way. I hate overly long and poorly organized backlogs because they suck up a lot of time and energy without delivering much value. And the longer and more unwieldy they get, the less likely it is anything will happen. I sometimes refer to these things as idea shredders. Good stuff goes in, and then nothing happens. Anyway, I'd be curious to learn what others are doing with their backlogs.
korse 2y ago
>hijacking the agenda to turn the meeting into a brainstorming session As someone who has reason to call technical meetings on a regular basis, I've always had trouble with this. Do you mention 'brainstorming' in the agenda? Do you use a different header? Most of the meetings I end up having are only vehicles to get necessary players into the same room and engaging in dialogue about a problem with a technical angle. Advice appreciated.
- lizard 2y ago
  There are almost certainly different approaches depending on the environment and situation. But, especially if this is a "culture" problem one of the best fixes I've found is to make shorter meetings with a defined agenda, such that you can always pull out a, "I'd love to take this offline, but we need to get back to..." I've personally found you should almost never need more than 30 minutes unless you specifically want to get into rabbit holes. And if you do need more than 30 minutes, it's probably better to split it into multiple sessions of no more than 30 minutes anyways to prevent this from happening. If you still have this problem at 30 minutes, shave 5 from either side (or both), which you can even use the excuse of giving time to transition between meetings. That's not to say you shouldn't genuinely allow room for brainstorming, but if you're going to take an entire room of peoples time, make sure it's something the room agrees is worth discussing and find another time to do it instead of getting sidetracked now. If not, offer some 1-on-1 time, and move on.

ryandrake 2y ago

In most companies I've worked, in order to actually implement an idea, you need to prove a few things, whether the person proposing it is the PM, an engineer, or any other person involved in the product: 1. The idea is technically feasible 2. The idea aligns with company's business goals 3. The idea is our team's responsibility and cannot be done by another team 4. The idea is more important than the other things our team plans to work on in the future 5. The idea is more time critical than the other things our team is working on now If any of these cannot be proven, then it goes on the backlog as a P4 and nobody realistically will ever look at it. It's just the reality of corporate software building. There are always 10-50x more ideas than there are staff/time to work on. Of course, all five of those can be, and often are, overridden by the Prime Directive: 0. One of the executives (often one of your grand-bosses high up on the totem pole) wants it.

p1necone 2y ago
In my experience the more fine grained an organizations issue tracking/planning is the more this is a problem vs a reasonable process. If you have to convince someone of all of those things in order to build some reasonably large thing over the space of a few weeks, that's probably reasonable. If you have to convince someone of all of those things in order to allocate a few hours to fixing some tech debt or minor bug then your codebase is going to slowly deteriorate until the same someone is asking you why there's so many bugs and everything takes so long to develop.
- elevatedastalt 2y ago
  Usually most engineers have some slack time and can pick things up to fix. The problem is not in them doing that. The issues arrises in one of two things— [1] They either use the fact that they are fixing that thing as an excuse to not work on or deliver on time a different, more important task. If that happens, obvious questions about prioritization occur. [2] They want a substantial amount of credit or recognition for doing it. Usually such fixes don't receive exec attention (since execs are tracking more important projects) and so don't get the same due as a properly tracked project does.
  - wbl 2y ago
    3: the fix is easy but the integration testing and deployment cannot happen without allocated time.
    - titusjohnson 2y ago
      In my experience this aspect is chronically underestimated by devs. The change needs testing. Change Management might need to create artifacts. Help articles might need updating. Certain clients may need a heads-up. All the PMs need to be briefed (this change is outside of their roadmap so it'll be a fun surprise). As an org grows the piece of the Effort Pie that is Development gets smaller and smaller. It's not that development gets easier, it's that every other part of the process grows in size and importance faster than the Development piece grows. It takes about an hour of developer time to incidentally produce 20 hours of work elsewhere in the company.
  - deleted 2y ago
    [deleted]
Dylan16807 2y ago
If it meets 1-4 does it get forgotten or does someone reliably come back to check for 5 becoming true?
- joshuanapoli 2y ago
  Probably the person who came up with the idea remains the most invested in it, and they should to watch for number 5 “the right moment” to bring it up again.
psunavy03 2y ago
Or you work at a non-software company where the technical folks ultimately report to a non-technical boss, or are outnumbered by nontechnical executives. In which case, there's the real danger of a bunch of 0 getting shoved down your collective throat to the tune of "it's all a priority, get it done."
- asoneth 2y ago
  > "it's all a priority, get it done." Reminds me of a product owner I had who abused priority categories by insisting that the majority of his tasks were "top priorities" because he had discovered that any time he didn't mark a task as a top priority it wouldn't get done. Every team ended up sorting his tasks as a flat list so that when he asked people to "make this a top priority" it was up to him to decide where it went in the list and which of his other requests would get bumped.
  - skydhash 2y ago
    That reminds me of a technique in the Slow Productivity book by Carl Newport. The gist is, if you cannot control the flow of work, the best thing to do is to create a buffer and make the workload visible. So they can visualize how any new task is going to disrupt it.
dyarosla 2y ago
Also, but rarely: Some engineer wants it bad enough that they just build it -or some version of it- and then some executive gives the go-ahead to invest more into it. At the end of the day, ideas are just ideas. Execution is everything.
- 3vidence 2y ago
  I've learned the value of this. Some people don't realize the value of something unless you show it to them. It's a risk for sure but honestly it keeps me sane vs trying to get 10 people aligned before starting something and then running out of time. People will happily take credit for your work after it works.
  - unkulunkulu 2y ago
    yep, an engineer has the power to directly influence the code. This is a strong power. Sometimes just making a PR is enough and a good convincer in and of itself. Use sparingly of course, weigh in time for making the argument, but this is an artifact just as a convincing research, text or a plot. code can be part of the argument.
  - sfn42 2y ago
    I once worked on an application that integrated with a third party api. The way it did this was with a large and horrible client library that used a separate db to cache the data. The data was then fetched from the main application and used to rebuild the pages (in the main db) based on this data once a day. The library had lots of problems, and one day it stopped working. I was tasked with fixing it - we had the source code, it was purchased from someone and copied into the repo. I spent most of the week if not more trying to figure out what was wrong, but I couldn't. What I did learn was that this library was some of the worst most pointless code I'd ever seen. So I told the team that I think I can rebuild this thing from scratch faster than I can fix this bug. The intermediate db is pointless and most of the library code is dead, the rest is garbage. I can make a simple little thing that does exactly what we need better, faster and easier. Nope. No bueno, fix what we have. So I spent a few hours over the weekend, less than a workday, building the new solution. Come Monday I had it pretty much working, a few things needed to be done but it already supported the use case. The pages were built correctly, they had the necessary content but some things were a bit messed up, nothing difficult to fix. Showed it to the team, said I want to use this and delete the old stuff - nope. The only half-decent explanation I got was that the client had paid a way too high amount of money for this garbage library and I guess the team lead didn't want to tell them we wanted to throw it out or something like that.
thaumasiotes 2y ago
> 3. The idea is our team's responsibility and cannot be done by another team Is it really true that your company cannot implement any idea that could potentially be done by more than one team?
- droopyEyelids 2y ago
  If more than one team could reasonably be the owner of something, -and- the ownership isn't going to get a manager promoted, there needs to be a showdown to see what team takes the impact to their roadmap

giancarlostoro 2y ago

"Add it to the backlog for review, we're not saying it'll be done, but it will at least be looked at an considered when we have bandwidth" Just be direct and realistic. If it's to a customer, "we'll add it to our backlog for review" and tag it as customer suggestion so it doesn't just sit there forever.

ghaff 2y ago

At a higher level, does the revenue it could result in be enough to move the needle and therefore be worth the attention up and down and across the management chain (to the degree it's a discrete program)?

jillesvangurp 2y ago
A good notion for value is that of option value. Not a lot of product managers understand this notion very well. Engineers tend to intuitively get this but they can't articulate it. You do work now to give you the option to do something later. Very simple really. PMs really don't get this. All this refactoring, over engineering, and whatever you want to call it. They'd prefer you to not do any of it. But of course engineers understand that those things can pay back later. Option value is a notion that Don Reinertsen promotes in his Lean 2.0 notion (google that and his name, mandatory stuff for wannabe PMs IMHO). Very simply put, he draws an analogy with stock options. They give you an option in the future to get some value. But there's a chance they'll be worthless and that you lose your money. The point is that the payoff can be much larger than the value loss. That's why they are popular tools for stock traders. There's a non linear relation loss-profit function. Which means you only need a few of your options to convert to profit to finance all of them. VC capital is based on this notion as well. Most startups are a write off. But a handful turn into unicorns and pay for the rest. In product management, option value is the notion that some idea might be worthless but could end up being worth a lot. Doing a lot of work on something that's just not worth a lot is probably wrong. Doing a little bit of work on something that might have a huge payoff is probably smart. Even if it's slightly risky or uncertain. Doing a lot of work on a lot of things that might be valuable like that at the cost of stuff that you actually should be doing is probably not optimal and very risky. But you should be taking some calculated risks at least part of the time just in case. Worst case you lose some time. Best case you create a lot of value in a way that you never planned to. Balancing risks is your job as a PM. The point here is that if you only do planned things and don't even entertain doing things that might be valuable outside of that scope, you are probably destroying a lot of value and you are placing a risky bet on your plan instead. If the plan is wrong, you might lose everything. Which is one of Reinertsen's key arguments against the original lean movement. You throw out the baby with the bath water if you do that. Bad idea for startups because you now make a risky bet on your plan being correct. Which of course it often isn't in startups. Pivoting is the notion of being able to turn a bad plan around. That gets easier if you invested in some option value that gives you the option to do so. A lot of unicorns emerged out of the ashes of failed startups. Big organizations are notorious for being risk averse and not having the internal capability to innovate even after they've identified the need to do so. As soon as management chains get involved, that's what happens.

cwbrandsma 2y ago

You forgot: Engineering is requesting this. So no.

jillesvangurp 2y ago

I like turning negatives into positives, as a way of providing constructive feedback. I'm doing product management on the side (I'm the CTO and also do a lot of the engineering) and the key issue I face is dealing with a large influx of good ideas and dealing with that in a way that minimizes my time having to evaluate things in our backlog. Saying no in a constructive way without pissing people off is key to being a good product manager. You need to be firm and decisive. But also very clear. The way I deal with this is several custom fields in our issue tracker kanban board that qualify any idea, no matter how good, crazy, in-feasible, etc. The most important ones are: - Value & Effort (one field) this is a quadrant of HighLow, HighHigh, LowLow, LowHigh. It's a reflection on what we would get out of doing something with the idea. High value and Low effort means you need a good reason not to kick an idea further. Low value and High effort kind of means a no, unless there's a really good reason. Anything in between can be decided on a case by case basis. I like the Low effort ones. They may not be that valuable. But sometimes they are nice to do. And you can just squeeze them in. - Next Step: This is a range of values that provide me an indication of when I should look at it again. Some things need to be fast tracked. Some things need more discussion/elaboration. And the rest is stuff that we might revisit or reject right now. I don't tend to spend time on rejected ideas unless somebody brings those to the table again. Things that linger too long without being actioned are going to end up labeled as rejected. Which just means they stop consuming my time. I have a few other fields (tags, priority, etc.) that are a bit more standard. But those two are the primary tools I use for deciding where to bucket ideas and how often to look at them. I should spend more time on high value ideas than on low value ones. And I should prioritize actioning items that have a next step that says I should do so. Anything else I can safely ignore indefinitely. If somebody doesn't agree, we can always discuss and change it. But there needs to be a good reason. This isn't perfect but it's a good mental model of dealing with incoming ideas in a bit structured way. I hate overly long and poorly organized backlogs because they suck up a lot of time and energy without delivering much value. And the longer and more unwieldy they get, the less likely it is anything will happen. I sometimes refer to these things as idea shredders. Good stuff goes in, and then nothing happens. Anyway, I'd be curious to learn what others are doing with their backlogs.

korse 2y ago

>hijacking the agenda to turn the meeting into a brainstorming session As someone who has reason to call technical meetings on a regular basis, I've always had trouble with this. Do you mention 'brainstorming' in the agenda? Do you use a different header? Most of the meetings I end up having are only vehicles to get necessary players into the same room and engaging in dialogue about a problem with a technical angle. Advice appreciated.

lizard 2y ago
There are almost certainly different approaches depending on the environment and situation. But, especially if this is a "culture" problem one of the best fixes I've found is to make shorter meetings with a defined agenda, such that you can always pull out a, "I'd love to take this offline, but we need to get back to..." I've personally found you should almost never need more than 30 minutes unless you specifically want to get into rabbit holes. And if you do need more than 30 minutes, it's probably better to split it into multiple sessions of no more than 30 minutes anyways to prevent this from happening. If you still have this problem at 30 minutes, shave 5 from either side (or both), which you can even use the excuse of giving time to transition between meetings. That's not to say you shouldn't genuinely allow room for brainstorming, but if you're going to take an entire room of peoples time, make sure it's something the room agrees is worth discussing and find another time to do it instead of getting sidetracked now. If not, offer some 1-on-1 time, and move on.