Backlog size is inversely proportional to how often we talk to customers(bitbytebit.substack.com)
bitbytebit.substack.com
Backlog size is inversely proportional to how often we talk to customers
https://bitbytebit.substack.com/p/the-size-of-your-backlog-is-inversely
173 comments
I totally agree. The worst thing is going directly from feedback -> ticket. Not only because of what you describe, but also because you end up with a product that is just a list of features without a coherent "idea". Especially when you've got eager developers that will see some slack in the schedule and just pick up a random ticket because it's "easy".
Usually when customers give feedback it's to address an immediate need they have, so they'll suggest adding a button/option/toggle/whatever. And that's fine, but if you do that for every piece of feedback, you'll end up with an unusable mess. Especially because it's usually very easy to add that one extra button/option/toggle.
You usually require someone to go through all the feedback and try to address the root cause of what they're asking for. Sometimes the extra option is unavoidable, sometimes it leads to redesigning some system to be more generic to support what the customer wants + more.
I do think the feedback needs to be linked to the work somehow, not hidden away in a separate PM tool or whatever. Ideally retaining the raw feedback, because sometimes when summarizing it, things get lost.
Usually when customers give feedback it's to address an immediate need they have, so they'll suggest adding a button/option/toggle/whatever. And that's fine, but if you do that for every piece of feedback, you'll end up with an unusable mess. Especially because it's usually very easy to add that one extra button/option/toggle.
You usually require someone to go through all the feedback and try to address the root cause of what they're asking for. Sometimes the extra option is unavoidable, sometimes it leads to redesigning some system to be more generic to support what the customer wants + more.
I do think the feedback needs to be linked to the work somehow, not hidden away in a separate PM tool or whatever. Ideally retaining the raw feedback, because sometimes when summarizing it, things get lost.
OTOH, evaluating feedback and determining whether it is actionable is itself work. So you need some sort of system to track the feedback you're getting, discuss it, make decisions about whether and how to implement anything in response to it, and then scope the downstream work you are going to do. And that sounds like the job of a ticketing system.
Maybe you don't want raw feedback dumped directly into your development board, so you might not just add extra columns to it, but another parallel board whose "done" column flows into the dev board's backlog seems like a reasonable approach.
Maybe you don't want raw feedback dumped directly into your development board, so you might not just add extra columns to it, but another parallel board whose "done" column flows into the dev board's backlog seems like a reasonable approach.
The central paradox of product development: planning is work, and eventually planning is enough work that you need to plan to plan to plan to plan and the whole thing collapses because you try to systematize judgement too far up the value stream.
Pretty on point.
Yeah, I agree with that. I should have been more specific in my comment. Going directly from feedback to _development ticket_ is (sometimes) bad. Sometimes when it's just "this is broken", it's fine.
I agree that you need some system to track feedback. I'm not convinced a board is the optimal choice, because (some?) feedback is kind of timeless. In my mind, it is never "done". Feedback can apply to future features that haven't been thought of yet when the feedback was originally processed, so it's valuable to keep it around in some sort of tag based system. You probably want a way to easily search it as well when designing new features.
I agree that you need some system to track feedback. I'm not convinced a board is the optimal choice, because (some?) feedback is kind of timeless. In my mind, it is never "done". Feedback can apply to future features that haven't been thought of yet when the feedback was originally processed, so it's valuable to keep it around in some sort of tag based system. You probably want a way to easily search it as well when designing new features.
https://www.getcustomeriq.com/ is pretty much dedicated to "evaluating feedback and determining whether it is actionable" fwiw
I agree, but it's also important to note that the relationship 'customer request' <=> 'ticket' is often not one to one. A PM will have multiple customer requests that slightly overlap, but not fully, and requests that make more sense as multiple tickets.
In my experience it's really better to keep requests in a lightweight PM tool until they have garnered enough interest to write out as a ticket. The tool I use is Dynalist, really just a glorified todo app, where you can sort/collapse things that go together but there are a million tools like it. Only when there is some certainty it will ever be built does it get a proper ticket for the devs to look at.
In my experience it's really better to keep requests in a lightweight PM tool until they have garnered enough interest to write out as a ticket. The tool I use is Dynalist, really just a glorified todo app, where you can sort/collapse things that go together but there are a million tools like it. Only when there is some certainty it will ever be built does it get a proper ticket for the devs to look at.
Feedback is a good use case for custom issue types, though. We create feedback issues that are not actionable of themselves, but can be linked to tickets, so engineers get a feeling of what customers think.
[deleted]
Where do you keep those to avoid cluttering the "real" backlog? Separate Jira (if applicable) project?
We have a ticket status in JIRA called "Parked". It allows us to capture the feedback so the stakeholder doesn't feel ignored. And if we get repeated requests, we can find it, bring it out of parked, and it starts to become a real thing.
There is the issue of dupes but it avoids the other issue, which is that if you hard decline too many requests from right after they are submitted, stakeholders may stop giving you feedback, which is a bad thing. So it is an unhappy middle ground (which is I feel the normal place which product management occupies. I could setup a small shop in the unhappy middle ground and sell souvenirs.)
There is the issue of dupes but it avoids the other issue, which is that if you hard decline too many requests from right after they are submitted, stakeholders may stop giving you feedback, which is a bad thing. So it is an unhappy middle ground (which is I feel the normal place which product management occupies. I could setup a small shop in the unhappy middle ground and sell souvenirs.)
There are products for those like https://www.productboard.com/ or https://harvestr.io/
And Atlassian’s own Jira Product Discovery (JPD) backlog management tool that integrates with Jira:
https://www.atlassian.com/software/jira/product-discovery
https://www.atlassian.com/software/jira/product-discovery
Tossing https://www.getcustomeriq.com/ in the mix - pretty much dedicated to this
Even in jira you can filter your backlog by issue type. (Not saying it's the best approach, separate project and links might work better, because the workflow is different).
Product management tools typically handle this. Jira Product Discovery and tools like Kitemaker keeps that information close to where the rest of the team works :)
Jira service desk to a separate backlog which is reviewed and filtered.
> and store other ideas elsewhere.
Why? Why have two places for the same thing? It's just an awkward tagging system. When would you search this but not search tickets?
Alternatively, just don't write them down. If you don't get a benefit from keeping the idea, don't write it down.
Mid-option, I think linear does this by default, cancel backlog items older than X. Not been touched or moved? Probably not relevant. Plus you can always search through cancelled tickets.
Why? Why have two places for the same thing? It's just an awkward tagging system. When would you search this but not search tickets?
Alternatively, just don't write them down. If you don't get a benefit from keeping the idea, don't write it down.
Mid-option, I think linear does this by default, cancel backlog items older than X. Not been touched or moved? Probably not relevant. Plus you can always search through cancelled tickets.
> Why? Why have two places for the same thing? It's just an awkward tagging system. When would you search this but not search tickets?
A ticket is a different level of detail. Takes more time, thought and effort to put together a good ticket. If it's for something that's not going to happen for 12 months, then there will have been enough change in the product/org/etc. that the original ticket won't work as written anyway.
A doc with a bunch of categorized feature ideas has enough info that you don't lose any good ideas, and then when it's actually time to attack one of those categories, then you can do the work of building out actual, ready-for-implementation tickets.
> Alternatively, just don't write them down. If you don't get a benefit from keeping the idea, don't write it down.
Totally agree with this. A lot of stuff isn't worth writing down. If it's way out in the future and really important, it'll come up again anyway.
A ticket is a different level of detail. Takes more time, thought and effort to put together a good ticket. If it's for something that's not going to happen for 12 months, then there will have been enough change in the product/org/etc. that the original ticket won't work as written anyway.
A doc with a bunch of categorized feature ideas has enough info that you don't lose any good ideas, and then when it's actually time to attack one of those categories, then you can do the work of building out actual, ready-for-implementation tickets.
> Alternatively, just don't write them down. If you don't get a benefit from keeping the idea, don't write it down.
Totally agree with this. A lot of stuff isn't worth writing down. If it's way out in the future and really important, it'll come up again anyway.
Backlog items can start as rough ideas though. Refining of a ticket can be done later when you need to. But it can only be started to be worked on when the team thinks it is refined enough.
In my experience, if you go this route what you end up with is a thousand tickets with a title and little to no description text that eventually get deleted because you can't figure out what it was about six months later (even if you're the one who wrote it).
And that problem somehow goes away if you store that same information in a separate system?
No, but it's about keeping the ticket box signal to noise ratio in check. One box for actionable, high signal items. One box for all the ~junk~ ideas.
Junk ideas are useful to document too. When the idea resurfaces, one can read why it did not get through the first time.
A ticket-system like JIRA is the same as an e-mailclient to me. You sort by activity, having the most active tickets on top. You can flag/mark them, you can put them in different boxes or just use tags,... All are just means to create order in chaos.
But I would never think to move my old e-mail to a different 'system' than my normal e-mail(client). I never think of old e-mails or drafts as something I need to clean up.
A ticket-system like JIRA is the same as an e-mailclient to me. You sort by activity, having the most active tickets on top. You can flag/mark them, you can put them in different boxes or just use tags,... All are just means to create order in chaos.
But I would never think to move my old e-mail to a different 'system' than my normal e-mail(client). I never think of old e-mails or drafts as something I need to clean up.
Those don't need to be separate systems, and keeping them in one system is often beneficial to see the evolution of the concept.
I'll frequently have an idea and toss it into a backlog ticket. Maybe just as a title to start. When a customer mentions that problem/feature, I can add that info in the backlog even if it doesn't immediately become a priority.
When the issue does become something worth working on, I'll usually add more details but the various evidence accumulated over 6 months of letting the item "bake" is invaluable.
I'll frequently have an idea and toss it into a backlog ticket. Maybe just as a title to start. When a customer mentions that problem/feature, I can add that info in the backlog even if it doesn't immediately become a priority.
When the issue does become something worth working on, I'll usually add more details but the various evidence accumulated over 6 months of letting the item "bake" is invaluable.
They don't need to be in principal. But in practice I've yet to find a tool that does both things well.
Why does your second system get to have information written in it that the first doesn't, or get to be more vague? You can write tickets at any level of detail.
You can then just tag them.
This means that a search can ignore them, or it can bring them up while you're looking at features/etc.
You can then just tag them.
This means that a search can ignore them, or it can bring them up while you're looking at features/etc.
> You can then "just" tag them.
All that administration overhead is why the ticket based system doesn't get this information. If it takes 30 seconds to create (and properly organise/categorise) a ticket then that's too slow. I want to be able to write tickets as fast as someone can say them, and move/reorder them with my usual copy paste / text editing tools.
All that administration overhead is why the ticket based system doesn't get this information. If it takes 30 seconds to create (and properly organise/categorise) a ticket then that's too slow. I want to be able to write tickets as fast as someone can say them, and move/reorder them with my usual copy paste / text editing tools.
This seems like a very niche and uncommon request. The vast, vast majority of tickets I've worked on (90%+ for sure, maybe 95%+) have had multiple people putting in context, additional information, related/blocking/blocked links, reproduction steps, accessibility requirements, security requirements, etc. Not all tickets require all this info, but most of them require at least a couple of these categories. I obviously don't have the hard data but I would hazard a guess that the median ticket I deliver has been at least 15-20 minutes of total work from at least 2 or 3 people. Much higher when you're talking about greenfield development of something that is getting any level of scoping ahead of time.
This is across 8-10 jobs in multiple industries over close to 20 years. Some places have been better or worse than others but I can't think of any place where people routinely were creating, organizing, and categorizing tickets this quickly, at least not tickets that had any value to anyone other than them as a reminder to do one very specific thing.
This is across 8-10 jobs in multiple industries over close to 20 years. Some places have been better or worse than others but I can't think of any place where people routinely were creating, organizing, and categorizing tickets this quickly, at least not tickets that had any value to anyone other than them as a reminder to do one very specific thing.
> I would hazard a guess that the median ticket I deliver has been at least 15-20 minutes of total work from at least 2 or 3 people
Sure, for tickets that you deliver. But when we're talking about managing a backlog there might be 50 potential tickets that never get implemented (or even scoped) for every one that does. And you don't really want those to ever become a ticket at all because that ends up being far too much product work, precisely because it takes ~20 minutes for each ticket.
Put another way: you need a way to track high-level work for prioritisation before putting too much into scoping and detailing what implementing it would involve.
Sure, for tickets that you deliver. But when we're talking about managing a backlog there might be 50 potential tickets that never get implemented (or even scoped) for every one that does. And you don't really want those to ever become a ticket at all because that ends up being far too much product work, precisely because it takes ~20 minutes for each ticket.
Put another way: you need a way to track high-level work for prioritisation before putting too much into scoping and detailing what implementing it would involve.
There are feature requests and there are what I would think of as design decisions / genuine defects depending on how you see it.
For example, ctrl shift v is how you paste unformatted in ms teams. You’d think by that logic, ctrl shift c would be copy but no it starts a call. There is no built in way to eliminate that and when I ask ms people they say “oh use powertoys and blah blah I had to do the same”.
There are multiple times this has been raised on the forums
https://answers.microsoft.com/en-us/msteams/forum/all/turn-o...
Do you want to put things like this on a different list, basically a “won’t fix” list? Why even write them down? Just to make people think you are listening?
For example, ctrl shift v is how you paste unformatted in ms teams. You’d think by that logic, ctrl shift c would be copy but no it starts a call. There is no built in way to eliminate that and when I ask ms people they say “oh use powertoys and blah blah I had to do the same”.
There are multiple times this has been raised on the forums
https://answers.microsoft.com/en-us/msteams/forum/all/turn-o...
Do you want to put things like this on a different list, basically a “won’t fix” list? Why even write them down? Just to make people think you are listening?
They are not the same thing.
A ticket is something where there is an understanding that we want to do it if time and resources permit, something where it would be okay for someone to grab it and do it.
On the other hand, an idea or suggestion may easily be something that should not ever be done, that drives the product in an inappropriate direction or adds an ability that we don't really want to exist for various reasons; and that is conceptually fundamentally different and should be kept in a separate place from the "big todo list".
A ticket is something where there is an understanding that we want to do it if time and resources permit, something where it would be okay for someone to grab it and do it.
On the other hand, an idea or suggestion may easily be something that should not ever be done, that drives the product in an inappropriate direction or adds an ability that we don't really want to exist for various reasons; and that is conceptually fundamentally different and should be kept in a separate place from the "big todo list".
> A ticket is something where there is an understanding that we want to do it if time and resources permit, something where it would be okay for someone to grab it and do it
If you want it to be that, sure. They're really just notes with IDs and tags. What you're describing is a curated backlog / upcoming work.
> On the other hand, an idea or suggestion may easily be something that should not ever be done
Ok? So either say why and cancel the ticket or delete it if you don't want a record of it. I don't get the value of writing it down in a different place so that you have to search in two places.
If you want it to be that, sure. They're really just notes with IDs and tags. What you're describing is a curated backlog / upcoming work.
> On the other hand, an idea or suggestion may easily be something that should not ever be done
Ok? So either say why and cancel the ticket or delete it if you don't want a record of it. I don't get the value of writing it down in a different place so that you have to search in two places.
How's is "cancel after X days" any better? Are there not enough decades-old bugs around to illustrate how it's not a good proxy? Why search through cancelled tickets which are resolved to find and unresolved issue? That's just a category error
The vast majority of tickets that haven't had any interaction for some length of time are irrelevant, it's an excellent proxy.
But it's worth reading the comment in context. If your problem is that old tickets are a nuisance because they're almost always irrelevant, just have them auto cancel and when you get that notification rescue the 2 per year that you truly want to keep.
If you don't have that problem, keep them.
> Why search through cancelled tickets which are resolved to find and unresolved issue?
Why would resolved tickets be cancelled?
Also, why search through two different systems?
But it's worth reading the comment in context. If your problem is that old tickets are a nuisance because they're almost always irrelevant, just have them auto cancel and when you get that notification rescue the 2 per year that you truly want to keep.
If you don't have that problem, keep them.
> Why search through cancelled tickets which are resolved to find and unresolved issue?
Why would resolved tickets be cancelled?
Also, why search through two different systems?
It's just an excellent proxy of insufficient resources, nothing more. A missing feature doesn't automagically appear with time to make the ticket irrelevant. If it's not relevant, it shouldn't be in the system in the first place
> when you get that notification rescue the 2 per year that you truly want to keep.
That makes even less sense. Looking at notifications and making a decision on closing/reopening is a form of review. If you have time to review, do it properly on your own schedule and in batches rather than be beholden to some arbitrary autoclose timeline with yet another focus-destroying trickle of notifictions
> when you get that notification rescue the 2 per year that you truly want to keep.
That makes even less sense. Looking at notifications and making a decision on closing/reopening is a form of review. If you have time to review, do it properly on your own schedule and in batches rather than be beholden to some arbitrary autoclose timeline with yet another focus-destroying trickle of notifictions
> If it's not relevant, it shouldn't be in the system in the first place
It was when it was created, it's not now. And it is then practically removed.
Again you can build whatever workflow you want, tag stuff or move things if they're super important to you. Subscribe to them if they're vital. Or don't auto close if that doesn't work for you.
I don't think that having a tiny number of issues that are
* Never looked at
* Never prioritised
* Never searched for
* Not subscribed to by anyone that cares about them
* Somehow super important to not have a "cancelled" status on them
Should define your workflow to this degree that you start keeping multiple lists of work. I'm not sure I've ever come across an issue worth leaving like this. Can you tell me about an issue that fits this description?
It was when it was created, it's not now. And it is then practically removed.
Again you can build whatever workflow you want, tag stuff or move things if they're super important to you. Subscribe to them if they're vital. Or don't auto close if that doesn't work for you.
I don't think that having a tiny number of issues that are
* Never looked at
* Never prioritised
* Never searched for
* Not subscribed to by anyone that cares about them
* Somehow super important to not have a "cancelled" status on them
Should define your workflow to this degree that you start keeping multiple lists of work. I'm not sure I've ever come across an issue worth leaving like this. Can you tell me about an issue that fits this description?
That's not a proper description (why is it suddenly vital/super the only alternatives to irrelevant?), why would I look for an example that fits?
> It's not now
You don't know that, in the process you yourself proposed that determination was done when you get an autoclose notification
> It's not now
You don't know that, in the process you yourself proposed that determination was done when you get an autoclose notification
> When would you search this but not search tickets?
The trick is to have each "ticket" be basically a bullet point in a list (where lists are grouped by headings/subheading in a single document). Maybe some are 3-4 lines, but most will be a single line bullet point. That way you don't have to search it (which doesn't tend to work very well as you won't know what you're looking for), you can actually browse the entire document.
The trick is to have each "ticket" be basically a bullet point in a list (where lists are grouped by headings/subheading in a single document). Maybe some are 3-4 lines, but most will be a single line bullet point. That way you don't have to search it (which doesn't tend to work very well as you won't know what you're looking for), you can actually browse the entire document.
Although the approach seems fine, I don't think it creates an advantage. The situation is there are tickets in progress that have engineering consequences and then there is the backlog. How the backlog then gets used is 100% a question of convenience and any approach that works for the decision makers is fine. If they want to use the backlog as a way to plan upcoming work (as you seem to do) that is fine. If they want to use the backlog as a diplomatic tool to say no gently, also cool.
JIRA + a tree of tickets is so bad for project planning I recommend using the backlog as a diplomatic tool and a polite way of letting things get lost. It is is better to use advanced scheduling tools, like a spiral-bound notebook or sticky notes, rather than a backlog. The backlog is for management and politics.
JIRA + a tree of tickets is so bad for project planning I recommend using the backlog as a diplomatic tool and a polite way of letting things get lost. It is is better to use advanced scheduling tools, like a spiral-bound notebook or sticky notes, rather than a backlog. The backlog is for management and politics.
One manager had regular backlog grooming. Friday afternoon, go through them all. Some would age out, be not relevant or whatever and be closed. Some kicked to next quarter. But a lot actually happened. Oh, we got pages, let’s do this now.
Seemed super effective.
Seemed super effective.
> I recommend using the backlog as a diplomatic tool and a polite way of letting things get lost.
I hate this approach. I totally get it, to be clear. I've done it. But I hate it. It's a sign of a really bad culture if you have to placate people in this way.
If your senior leadership is clearly communicating priorities, you should be able to say, "Look, this is an interesting idea, but as you know this quarter we're very focused on X, and this just doesn't align with that. The best route to get this done is to give your feedback in the next planning process and see if you can push Y to be a priority, then we can definitely talk about getting this on the roadmap."
A huge part of the job of a PM is to say no. If people aren't able to take a no on feature requests, there's a problem somewhere. Maybe it's with the way you're delivering it, maybe it's with the overall culture or maybe it's with the person making the request. Whatever the issue is, though, it's better to deal with it and create an environment where people understand that sometimes their requests will get declined for valid reasons.
I hate this approach. I totally get it, to be clear. I've done it. But I hate it. It's a sign of a really bad culture if you have to placate people in this way.
If your senior leadership is clearly communicating priorities, you should be able to say, "Look, this is an interesting idea, but as you know this quarter we're very focused on X, and this just doesn't align with that. The best route to get this done is to give your feedback in the next planning process and see if you can push Y to be a priority, then we can definitely talk about getting this on the roadmap."
A huge part of the job of a PM is to say no. If people aren't able to take a no on feature requests, there's a problem somewhere. Maybe it's with the way you're delivering it, maybe it's with the overall culture or maybe it's with the person making the request. Whatever the issue is, though, it's better to deal with it and create an environment where people understand that sometimes their requests will get declined for valid reasons.
So nothing goes in the backlog? How do you keep track of ideas that might make sense but aren't high priority right now? If you have an idea to do X, and then over 2 years you find lots of customers asking for it and it's a few weeks work, how does that get captured somewhere?
If it's just a ticket in a 2000-task long backlog somewhere, it won't help much anyway. What you actually need to have around is the person who had the idea in the first place, so they can champion it, adapt it, and flesh it out.
But if they're around anyway, they can keep it in whatever personal backlog they have instead.
But if they're around anyway, they can keep it in whatever personal backlog they have instead.
This doesn't work at any reasonable sized org. Maintaining ideas in people's heads falls over quickly as people come and go.
It's work to keep a backlog not a total disaster, but that doesn't mean the answer is "tool x" or whatever. It's just work. Ugly annoying work. Ie, work.
It's work to keep a backlog not a total disaster, but that doesn't mean the answer is "tool x" or whatever. It's just work. Ugly annoying work. Ie, work.
> But if they’re around anyway, they can keep it in whatever personal backlog they have instead.
How should I manage my personal backlog? There’s over a 100 post-it’s on my desk. Should I create another backlog for longer-term ideas or maybe hire a personal PO?
How should I manage my personal backlog? There’s over a 100 post-it’s on my desk. Should I create another backlog for longer-term ideas or maybe hire a personal PO?
I use Apple Notes.
> Should I create another backlog for longer-term ideas
IMO yes. That way you can easily review it before meetings, and come ready to said meetings with your most important items. I think this is quite a personal thing, so this kind of workflow may not work for you. But I found it almost impossible to work without such a list.
> Should I create another backlog for longer-term ideas
IMO yes. That way you can easily review it before meetings, and come ready to said meetings with your most important items. I think this is quite a personal thing, so this kind of workflow may not work for you. But I found it almost impossible to work without such a list.
If history is a guide then the standard approach is:
Get a stable product and then wait till someone else does something innovative and copy that.
Get a stable product and then wait till someone else does something innovative and copy that.
Drop those ideas. Ideas are cheap. If it relevant in two year's time it will resurface naturally.
Bad ideas are cheap. Good ideas are extremely difficult to come by. The same idea might come by frequently and seem like a nothing each time. Product managers come and go.
There are whole classes of software that are built around aggregating and storing customer feedback in a more-raw format than JIRA tickets. See: Prodpad or Productboard or even JIRA product discovery.
Do you find that adds value, rather than creating another silo that basically serves the same purpose?
What do you use and what are its top features?
What do you use and what are its top features?
I use ProductBoard. It’s not perfect, but it basically does a good job of making it easy to get feedback into the tool, and then tag/sort/organize it in a variety of ways. At this point we’ve got 5k “insights” all tied to customers & prospects. It helps us identify smaller things we might have missed, and makes it really easy to get a lot of historical feedback quickly when we do decide to tackle a feature.
If done right it forces the asker to really think about and flesh out their idea, most ticket systems don’t necessarily enforce great descriptive hygiene. But if you use an idea portal you can force the requester to answer a bunch of questions with min char counts that make them really think about the idea, then they can get feedback from others who might have a similar problem. Additionally most other channels for receiving feedback are unstructured and won’t result in high quality feedback, nor an accurate description of the problem, these types of tools have a much better chance of getting real serious feedback, bec only the ones who really care will persevere through all the questions.
If you just drop every customer email complaining about a supposed problem into a ticket in your company’s private queue, no one but internal employees will ever see it (and 99% of those won’t ever notice it or read it) but if you give your users a place to vent and discuss their ideas (with moderation of course) you can have a pretty powerful new idea/roadmap tool.
If you just drop every customer email complaining about a supposed problem into a ticket in your company’s private queue, no one but internal employees will ever see it (and 99% of those won’t ever notice it or read it) but if you give your users a place to vent and discuss their ideas (with moderation of course) you can have a pretty powerful new idea/roadmap tool.
We have a lot of issues (nearing 1000) in a public repo[0] that anyone can view and vote on.
This gives us a natural filtering mechanism for community input. We regularly sort this by number of upvotes. It also lets our users submit some off the wall ideas, and gives a way for low friction community feedback to be captured. Finally, it lets community members easily be notified when a feature is delivered by subscribing to the issue.
We also have a separate, private list of commits to customers. (The commit is public and is added to a milestone, but the customer is private.)
We also group issues by theme[1]. It's not perfect but it's an attempt to make sure we don't run into the duplicates issue you mention. It allows the eng team to address multiple issues in the same area of the code at once.
I understand what you are saying about clutter, but the low cost public feedback and tight loop between issue and code is worth some issue creep, IMO.
0: https://github.com/FusionAuth/fusionauth-issues/issues
1: https://github.com/FusionAuth/fusionauth-issues/issues?q=is%...
This gives us a natural filtering mechanism for community input. We regularly sort this by number of upvotes. It also lets our users submit some off the wall ideas, and gives a way for low friction community feedback to be captured. Finally, it lets community members easily be notified when a feature is delivered by subscribing to the issue.
We also have a separate, private list of commits to customers. (The commit is public and is added to a milestone, but the customer is private.)
We also group issues by theme[1]. It's not perfect but it's an attempt to make sure we don't run into the duplicates issue you mention. It allows the eng team to address multiple issues in the same area of the code at once.
I understand what you are saying about clutter, but the low cost public feedback and tight loop between issue and code is worth some issue creep, IMO.
0: https://github.com/FusionAuth/fusionauth-issues/issues
1: https://github.com/FusionAuth/fusionauth-issues/issues?q=is%...
I see your product is for devs, so totally get this. I work in enterprise software and can't imagine this would work well.
That makes sense. I think you should tune your product management strategy for your audience.
Still think there's value in having an open roadmap and feature list that customers and users can submit too, regardless of industry. I wouldn't recommend you use GitHub, though :).
Still think there's value in having an open roadmap and feature list that customers and users can submit too, regardless of industry. I wouldn't recommend you use GitHub, though :).
Vote = vote * employee.grade
(/S this isnt actually a good idea but may be practical depending on the org)
(/S this isnt actually a good idea but may be practical depending on the org)
The best metric would likely be one that reflects closely the actual power distribution at a company. That makes the answer difficult, but it also makes me more interested in the idea of what would be a best fit.
As for my first attempt to guess the power structure: vote = 1 + sum(direct_reports.vote)
As for my first attempt to guess the power structure: vote = 1 + sum(direct_reports.vote)
It really depends on what your priorities are, its a key driver in defining the culture.. who do you listen to when considereing tranformation / change?
You could have a suite i guess.. maybe look for overlap?
Satisfaction? Vote = vote * staff turnover for voters role.
Greed? Vote = vote * voters team profit
Top down control? Vote = vote * voters grade
Reverse disfunction? Vote = vote * number of complaints raised by voter
Cross functional impact: vote = vote * num departments voting for this
My question marks reflect i have no idea what the real optimisation is when you select a defined metric / score.
In reality (as someone who wants to make things hollisticially better in a sustainable way) i look for the overlap of several things:
Who do people have on speed dial to fix issues? Will this reduce how many calls they get? Ignoring what official processes say.
Will this impact the bottom line?
Will it increase customer satisfaction?
What will be the impact on staff turnover? I prefer to reduce this but at least there needs to be a mitigation if its negative. Key questions are: will people better understand personal their impact on Cost and quality? Will this make success and failure clearer outcomes for the individual?
Then finally will this be a step towards or away from governance principals of org? E.g. does this cause party A to have needless influence or judgement over party B (at all levels).. basically will this enable individual agency at all levels.
I always justify it on paper in terms of governace efficiency/efficacy, profit and quality.
You could have a suite i guess.. maybe look for overlap?
Satisfaction? Vote = vote * staff turnover for voters role.
Greed? Vote = vote * voters team profit
Top down control? Vote = vote * voters grade
Reverse disfunction? Vote = vote * number of complaints raised by voter
Cross functional impact: vote = vote * num departments voting for this
My question marks reflect i have no idea what the real optimisation is when you select a defined metric / score.
In reality (as someone who wants to make things hollisticially better in a sustainable way) i look for the overlap of several things:
Who do people have on speed dial to fix issues? Will this reduce how many calls they get? Ignoring what official processes say.
Will this impact the bottom line?
Will it increase customer satisfaction?
What will be the impact on staff turnover? I prefer to reduce this but at least there needs to be a mitigation if its negative. Key questions are: will people better understand personal their impact on Cost and quality? Will this make success and failure clearer outcomes for the individual?
Then finally will this be a step towards or away from governance principals of org? E.g. does this cause party A to have needless influence or judgement over party B (at all levels).. basically will this enable individual agency at all levels.
I always justify it on paper in terms of governace efficiency/efficacy, profit and quality.
we use Atlassian. My engineering team works on a Jira Kanban that only contains tickets that are soon to be worked on (read: within the next days, tops), there is no backlog at all, and engineers are encouraged to put technical findings there and pull them if the team considers it important enough to act on it. In addition, our product team works with the "Product Discovery" tool from atlassian, where they collect Ideas/Features/..., determines the RICE score for each, and does the back-and-forth with people, until they are reasonably sure what to put into the engineering kanban next, always having the "WIP limit" in mind.
Therefore the giant "icebox" is out-of-sight but the social factor of "there is a ticket for my idea" across the company is also fulfilled. works pretty well so far!
Therefore the giant "icebox" is out-of-sight but the social factor of "there is a ticket for my idea" across the company is also fulfilled. works pretty well so far!
This is the answer. You can solve this problem with tools; you don't have to change your philosophy.
When your company has 5 projects, do you count Project Z's backlog against Project X's backlog? No you don't, even though they are both in the same database. The reason you're OK with this is because your teams' views have been adjusted so that they only see their own project. So they each see what they consider to be their own backlog. Use the same approach for low-priority requests: put them in the same database, but don't elevate them to the team's backlog view.
If someone has an idea or a request you should not suppress it entirely. That will only encourage people to add yet another system of logging to your organization. Just because a request is not urgent or can't be put on the roadmap yet does not mean it's not important.
And why throw away what can be logged for later archeology? "Oh hey the answer to this new problem is right here in this old request we never got around to."
When your company has 5 projects, do you count Project Z's backlog against Project X's backlog? No you don't, even though they are both in the same database. The reason you're OK with this is because your teams' views have been adjusted so that they only see their own project. So they each see what they consider to be their own backlog. Use the same approach for low-priority requests: put them in the same database, but don't elevate them to the team's backlog view.
If someone has an idea or a request you should not suppress it entirely. That will only encourage people to add yet another system of logging to your organization. Just because a request is not urgent or can't be put on the roadmap yet does not mean it's not important.
And why throw away what can be logged for later archeology? "Oh hey the answer to this new problem is right here in this old request we never got around to."
Nice! Having the same ticket going for months because it's always low priority, but always coming back during grooming is not a good feeling. I don't mind having a huge list of tasks, but only if I know they're going to be done eventually.
I get where you are coming at and find some value in it but I do often like to create these "maybe someday" tickets for a few reasons.
- It provides an obvious place to put some ideas about then that can be collected over time. Often thoughts from significantly different points in time can provide valuable perspective. Even if most of the time they are just out of date.
- It allows tracking value over time. For example adding a quick note that this would have been helpful to customer 123. If you only file tickets when you are ready to implement them it is easy to miss the common friction problems.
So basically it is a way to log interest over time. But they are also easy to filter out so low cost to keep them around.
But I'm sure that you could also manage these "feature requests" in a separate system. But that often adds friction.
- It provides an obvious place to put some ideas about then that can be collected over time. Often thoughts from significantly different points in time can provide valuable perspective. Even if most of the time they are just out of date.
- It allows tracking value over time. For example adding a quick note that this would have been helpful to customer 123. If you only file tickets when you are ready to implement them it is easy to miss the common friction problems.
So basically it is a way to log interest over time. But they are also easy to filter out so low cost to keep them around.
But I'm sure that you could also manage these "feature requests" in a separate system. But that often adds friction.
Agree with all of this, and recommend this process for engineering tech debt: https://max.engineer/long-term-refactors
In short: maintain a list of long term refactors that everyone's gradually working on, without necessarily showing it in the ticket tracking system.
In short: maintain a list of long term refactors that everyone's gradually working on, without necessarily showing it in the ticket tracking system.
This is perhaps implicit in your comment, but "no" is also an acceptable answer if you explain why. We have a product that we have a relatively clear idea about, where we spend a lot of time making sure we're keeping things simple and focused. I reckon we say "no" to at least one third of ideas and "not for quite a while" for at least another third, explaining why each time in terms of our roadmap for the product. We'd found that customers tend to respond quite well, and for those where it's a deal breaker, they're probably better served by a different product anyway.
> ...they're probably better served by a different product anyway.
And you are doing both them and yourself a favor by making this clear. You might lose a couple of customers. But you would have lost them anyway and unhappy customers can also be annoying for everybody and slow you down, give you less than favorable reviews, etc.
And you are doing both them and yourself a favor by making this clear. You might lose a couple of customers. But you would have lost them anyway and unhappy customers can also be annoying for everybody and slow you down, give you less than favorable reviews, etc.
The problem is that not saying no, dismissing it without details, or ignoring it in an icebox removes a key feature and the way we should organize that idea: why not.
Suppose the idea is likely impactful but complicated to implement. In that case, you might want to think about putting those ideas together to argue for refactoring that would enable more impactful ideas.
If the idea would change the kind of service being offered, then it should inform strategic product thinking.
If the idea is relevant but unlikely to have an impact because it's too low level and about code quality, maybe you want to think of automating or including it in the linting process.
I think the problem here is that the tool, Jira tickets, isn’t suited for the use that you make of it: communicating with clients and defining product strategy. The problem is that there isn’t a good tool for that.
Suppose the idea is likely impactful but complicated to implement. In that case, you might want to think about putting those ideas together to argue for refactoring that would enable more impactful ideas.
If the idea would change the kind of service being offered, then it should inform strategic product thinking.
If the idea is relevant but unlikely to have an impact because it's too low level and about code quality, maybe you want to think of automating or including it in the linting process.
I think the problem here is that the tool, Jira tickets, isn’t suited for the use that you make of it: communicating with clients and defining product strategy. The problem is that there isn’t a good tool for that.
Very similar to what's recommended in Basecamp's Shapeup book:
https://basecamp.com/shapeup/2.1-chapter-07
https://basecamp.com/shapeup/2.1-chapter-07
> I hate the strategy of just taking every idea you hear and throwing it into a ticket. You just end up with this giant icebox of stuff you'll never do. If a big new prospect demands one of the ideas that's in the icebox be implemented immediately in order to close a deal, you're probably still not going to pull it out of the icebox, because you don't remember that it's there. Instead, you'll just create a new ticket for it, and eventually when going through the icebox, someone will go "hey, I think we built this already" and close as dupe.
This was part of the wisdom of the ancient agile way: a box of index cards for your backlog. The physicality of it gave clear indication when it was getting silly. Furthermore, regular backlog pruning was a necessary activity because the box would get full!
This was part of the wisdom of the ancient agile way: a box of index cards for your backlog. The physicality of it gave clear indication when it was getting silly. Furthermore, regular backlog pruning was a necessary activity because the box would get full!
If Product Managers or Product Owners are creating new duplicate tickets instead of searching and updating existing tickets then they're simply not doing their job. Keeping the backlog groomed and being familiar with its contents is a core job responsibility. No process change can overcome that level of laziness and incompetence.
Totally agree re: everything's a ticket. I consider the backlog to be only prioritized work - things we determined need to happen they're just not happening right now. Features we've agreed on, tech debt, etc.
I do think it's important to organize all feature requests, pain points, feedback etc. though but it needs to be separate of delivery management and it should be thematic (assuming there's a lot of feedback). That's the point of CustomerIQ (I'm a founder), to give that a home but also quantify themes over time. These would inform the backlog/possible make it in, but keeps delivery tools cleans.
I do think it's important to organize all feature requests, pain points, feedback etc. though but it needs to be separate of delivery management and it should be thematic (assuming there's a lot of feedback). That's the point of CustomerIQ (I'm a founder), to give that a home but also quantify themes over time. These would inform the backlog/possible make it in, but keeps delivery tools cleans.
The way you need to model it is to mentally add friction/cost for retrieving tickets after some time. Doing things right now, without making them tickets is often easier, because the problems context is still fresh, both to you and your customer. So potentially needed clarifications are easier to get while things are fresh than if you made them a few weeks down the line. This is especially true if the customer asks about minor things and these are a blocker or a huge annoyance to them. Fixing them right away will make you shine more than just putting it on a stash.
But if you find yourself constantly fixing things that were specified and should actually work you got a problam with code quality. And if you constantly have to add small new things there is a problem with your customers clarity and a bigger meeting might be in order.
But if you find yourself constantly fixing things that were specified and should actually work you got a problam with code quality. And if you constantly have to add small new things there is a problem with your customers clarity and a bigger meeting might be in order.
You and I seem to completely agree on this. I really dislike a backlog of bad conscious with things we "mustn't forget". My reasoning is more (akin to yours): if it's a necessary and actually requested or useful feature, then we'll rediscover it. (This doesn't apply to bugs!)
I really like that. It also helps reassuring the importance of items. Like, if you want to create the same story three times in a year, it might actually be important.
Wouldn’t a curated version of the icebox help notice that pattern early? Especially if the team changes quite fast.
It's that for a team of a given size, we can only collectively produce so much. So as long as we're always picking tickets of a priority that stakeholders and we deem of the highest priority, then we're doing the right things.
This necessarily means that the backlog probably grows.
This necessarily means that the backlog probably grows.
I actually like it. Unfinnished Ideas are .. the waves the buisness problems make when bumping into the software. These ideas are usually collection points for notes on how something is impossible (due to reality, buisness or architecture) or otherwise constrained.
They are not actual features, they are a information collection on how a idea might be not possible or a placeholder for a better solution not yet in the making.
Not all tickets have to become a feature in software- some can become wikipedia pages on requirements/conditions of the project.
They are not actual features, they are a information collection on how a idea might be not possible or a placeholder for a better solution not yet in the making.
Not all tickets have to become a feature in software- some can become wikipedia pages on requirements/conditions of the project.
This is what David Marquet suggests too: the team backlog should contain whatever's going to happen in the next short iteration. The rest is dropped.
If someone wants to save an idea for a later iteration, they can do that however they want, but they don't get to clutter the team backlog with it.
It also mirrors my best experiences with well-managed backlogs.
If someone wants to save an idea for a later iteration, they can do that however they want, but they don't get to clutter the team backlog with it.
It also mirrors my best experiences with well-managed backlogs.
This proposal moves the list to other systems. I dislike unbounded backlogs too - but a single searchable database is better, IMO. (Though Github issues et. al. have such bespoke, bad, limited, bad, half-baked, bad search.. Gah.)
On the flip side, putting a ticket on the backlog knowing it will never be high enough priority to be done is an effective way to manage people's feelings without outright nopeing their idea.
The best products tend to have PMs willing to say No the most, though.
I've seen this approach in 100- startup and 10K+ enterprise: managers collect and store ideas in their private places.
This quickly turns into job security and spoils the work process.
To use an analogy of back pain and a massage.
You may get relief but you run up a cost and with no real solution to the problem.
Size of backlog is inversely proportional to PM turnover.
For old PM the backlog is a memory prosthesis of all the old product conversations (a graveyard of broken dreams).
New PM will look at backlog in horror "what even is this I don't understand it", declare bankruptcy, "clear all that crap out".
For old PM the backlog is a memory prosthesis of all the old product conversations (a graveyard of broken dreams).
New PM will look at backlog in horror "what even is this I don't understand it", declare bankruptcy, "clear all that crap out".
> New PM will look at backlog in horror "what even is this I don't understand it", declare bankruptcy, "clear all that crap out".
Especially when all the tickets in the backlog just have 1-2 sentences and can't possibly be understood without the context that lives in the head of the original PM who wrote them.
Especially when all the tickets in the backlog just have 1-2 sentences and can't possibly be understood without the context that lives in the head of the original PM who wrote them.
Oh man that cuts deep
---
"Redo John's fix for frobulator service"
Definition of done: The fix is implemented correctly.
---
"Redo John's fix for frobulator service"
Definition of done: The fix is implemented correctly.
Reposting my comment from a couple of months ago:
At one of my jobs, they used Asana when I started. It was too full of backlogged issues, so we moved over to Jira. Then Jira got too full. A month before I was laid off, one of my coworkers said, "Maybe we should try out Asana."
At one of my jobs, they used Asana when I started. It was too full of backlogged issues, so we moved over to Jira. Then Jira got too full. A month before I was laid off, one of my coworkers said, "Maybe we should try out Asana."
I fear to know what “Jira got too full” means but I suspect I’ll find out if I stay in my current workplace long enough.
I don't understand what full means. It is weird being at a place long enough to see ticket 1 and ticket 60k, though.
It means there are so many tickets that are never going to be implemented any time soon that it becomes hard to find the ones that are (or should be).
You should have just periodically flushed old tickets. Everybody would have been happy, and none the wiser :)
That is so toxic and just painful to read. Hard to understand how people function like that.
And sometimes new and old PM is future & past versions of the same person!
I disagree with the article. Every team I’ve worked on that maintains a backlog, got most of their backlog from customers.
And it’s not so easy as “find out what will make your customers lives better and make that your next feature”. What if you have more than one customer, and the features that will make their lives better are unrelated and each is large?
You should always listen to your customers. You should almost never build what they ask you for.
A customer will ask you for a feature like “put a button on the second screen that invokes this other tool”. Inherent in that request is not only a UX implementation, but also a statement of a problem that they have, and a muddled business process that they use at the current time.
You need to figure out what their business problem is, but throw away the ideas for UX implementation and anything process specific.
Then build the minimum feature that solves their business problem, in the most economical way for you, and consistent with good UX design. Bonus points for building lots of integration points that allow your customers to extend your software while isolating your customers business processes from your code.
And it’s not so easy as “find out what will make your customers lives better and make that your next feature”. What if you have more than one customer, and the features that will make their lives better are unrelated and each is large?
You should always listen to your customers. You should almost never build what they ask you for.
A customer will ask you for a feature like “put a button on the second screen that invokes this other tool”. Inherent in that request is not only a UX implementation, but also a statement of a problem that they have, and a muddled business process that they use at the current time.
You need to figure out what their business problem is, but throw away the ideas for UX implementation and anything process specific.
Then build the minimum feature that solves their business problem, in the most economical way for you, and consistent with good UX design. Bonus points for building lots of integration points that allow your customers to extend your software while isolating your customers business processes from your code.
> Every team I’ve worked on that maintains a backlog, got most of their backlog from customers.
Or maybe you aren't the one who calls Bob, but someone from Sales, or Customer Support is the one who calls Bob, so now you don't just have a back-log, you've got two panicked people who are sure Bob is going to take his business elsewhere.
First, Bob's easy. Bob cares about all of those little things but most of the time, Bob's not stupid. He's fully aware what's important and what's not, the reason he brings you the whole list is because he thinks that will get your attention better than it did when he brought up his "critical feature" that got sidelined. If you don't sell to thousands and thousands of customers, but hundreds with a tens of really important ones, and Bob's one of them, the problem is failing to apply empathy to the Bob problem. Personally, I love these guys because they're usually very easy to placate. Usually Bob's list has 100 things on it, 99 of which are solved with the same four lines of code, one of which is a horrible pain in the ass. Usually at the beginning of the conversation, all 100 are important, but after you finish 99 of them, sometimes Bob doesn't even notice the one that's missing, he's too shocked that not only did one thing get fixed, but his list is gone! Call Bob in a week to follow up; if you haven't been neglecting him too long, ... he's got one or two bullets or nothing at all.
But for all the others, yeah, the backlog will grow ... initially. If you keep following up, and keep reaching out, though -- you'll find your customers are on your back less because they know you know what you need to do and they know you're working on it. Over time, it becomes easier to temper expectations, you have fewer emergencies, things get scheduled more consistently and the backlog ... eventually starts to shrink again. Your customers not only have limits on the things they want/need out of your application, they also complain less and less feverishly about the things that do irritate them because it's "just the one button that's wonky" and not a thousand little paper-cuts of things that just don't seem to work like they should.
And yes, always listen to the customers/never build what they ask for ... except ... that's only good advice in very specific circumstances. If you know your customer's needs better than your customer does than that's the best advice you can take. For everyone else, "always listen to your customers until you understand it precisely on their terms" then start asking them questions to understand why it is they're asking for the thing they're asking for. The problem with the "the customer doesn't know what they need" premise is that if you dismiss what they're asking for and the thing you produce doesn't fit "the thing they were trying to accomplish by asking for that" everybody loses. Sometimes, hell often, you're better off giving the customer exactly what they asked for than missing the mark by even a small amount even if you provide something substantially better. What you end up with is "a cool feature that nobody wants because your customer really did just want the 'print to PDF' button because of some archaic fax workflow you were unaware of" (or insert some other weird example).
I'm not poking fun/chiding here -- I give the same advice to others all the time, but it's easy to forget that "you can't tell the customer what they want if you don't talk to your customers" :)
Heh. I'm a "Bob" for one of the products my company uses.
Everything else you write is spot-on, too. There's one issue with the way their their platform presents data to our customers that's been killing us - to the point that we've lost sales, and have consequently stopped using a major product feature. I've explained the issue to everyone from our customer reps, to sales engineers, to two successive SVPs of that product area. Everyone gets it; everyone says "oh, yeah: we need to fix that". It's been five years, and I've given up hope that it'll be fixed.
They've created another annoyance, which speaks to bad practice. Their reporting tool doesn't cover an edge case that we'd like to address. It's no problem, no one can think of everything; I'll use their data API to build a custom report for myself. Except... their API doesn't expose the one field I'd need to make my report possible. That data isn't a security concern, and is being used elsewhere in their standard reports. From that (and a couple of other examples), their report system clearly doesn't use their data API. Dogfood your APIs, people! (Five years of feedback, and that's never been fixed, either.) For the love of God, dogfood.
And, if you're going to solicit feedback from your customers, do something about it, or else explain why you won't. Don't solicit information, nod about it, promise fixes, then not. Don't then do the exact same thing again, with more senior people, a year later. I've built and maintained enough software to know that software is hard. I'm pretty sympathetic towards engineers, and fairly forgiving about software problems. At some point, however, these problems cease to be software problems, and I'm much less sympathetic about that.
So, everyone else reading this should take it from "Bob": this guy's advice is how to maintain your customers' faith in your product and your company.
Everything else you write is spot-on, too. There's one issue with the way their their platform presents data to our customers that's been killing us - to the point that we've lost sales, and have consequently stopped using a major product feature. I've explained the issue to everyone from our customer reps, to sales engineers, to two successive SVPs of that product area. Everyone gets it; everyone says "oh, yeah: we need to fix that". It's been five years, and I've given up hope that it'll be fixed.
They've created another annoyance, which speaks to bad practice. Their reporting tool doesn't cover an edge case that we'd like to address. It's no problem, no one can think of everything; I'll use their data API to build a custom report for myself. Except... their API doesn't expose the one field I'd need to make my report possible. That data isn't a security concern, and is being used elsewhere in their standard reports. From that (and a couple of other examples), their report system clearly doesn't use their data API. Dogfood your APIs, people! (Five years of feedback, and that's never been fixed, either.) For the love of God, dogfood.
And, if you're going to solicit feedback from your customers, do something about it, or else explain why you won't. Don't solicit information, nod about it, promise fixes, then not. Don't then do the exact same thing again, with more senior people, a year later. I've built and maintained enough software to know that software is hard. I'm pretty sympathetic towards engineers, and fairly forgiving about software problems. At some point, however, these problems cease to be software problems, and I'm much less sympathetic about that.
So, everyone else reading this should take it from "Bob": this guy's advice is how to maintain your customers' faith in your product and your company.
I didn't think you were poking fun, I think your advice is very insightful!
But yes, customer trust is based on both listening and delivering results that help them.
But yes, customer trust is based on both listening and delivering results that help them.
As a PM you need a place to register your customer needs. If you don't have a dedicated tool, needs mostly end up as tickets in Jira. So best to register them elsewhere.
I've seen two approaches to this, ProductBoard and Jira Product Discovery. ProductBoard has a CRM approach where you make a note of every customer interaction (call, meeting, email, support ticket, etc), and later you can break down the customer interaction into needs and wishes. So initially all you have is a list of customer interactions.
Jira Product Discovery starts with an idea. So if you want to keep track of everything you hear from your customers, you're forced to immediately break this down into a long list of all wishes and needs.
Benefit of Jira Product Discovery is that it keeps this long list of ideas out of the developer backlog, but it's yet another long list. You can connect Jira Product Discovery Ideas later to Jira epics and stories, so delivery is easier to track.
ProductBoard is the better product discovery tool if you want to analyze product priorities based on customer conversations. It has tools to aggregate and analyze the items mentions in these conversations.
I've seen two approaches to this, ProductBoard and Jira Product Discovery. ProductBoard has a CRM approach where you make a note of every customer interaction (call, meeting, email, support ticket, etc), and later you can break down the customer interaction into needs and wishes. So initially all you have is a list of customer interactions.
Jira Product Discovery starts with an idea. So if you want to keep track of everything you hear from your customers, you're forced to immediately break this down into a long list of all wishes and needs.
Benefit of Jira Product Discovery is that it keeps this long list of ideas out of the developer backlog, but it's yet another long list. You can connect Jira Product Discovery Ideas later to Jira epics and stories, so delivery is easier to track.
ProductBoard is the better product discovery tool if you want to analyze product priorities based on customer conversations. It has tools to aggregate and analyze the items mentions in these conversations.
What's the point though of this long list of ideas or wishes? Are you worried you'll forget what's important and start working on something that doesn't matter if you don't have it?
To do objective, measurable, data driven roadmap prioritization. You want to be able to show how often certain features or capabilities were requested, in what context, and what the impact would be, both on the customer and on sales targets.
To do this you need complete observability of all customer interactions, i.e., meeting/call notes, presales notes, forum posts, zendesk support tickets, services interactions, etc. Productboard goes quite far in enabling you to bring all these channels together so you can build a data driven roadmap. Jira Product Discovery on the other hand is quite thin on this, more focussed on handover to the development teams, showing roadmaps, and tracking progress. Hopefully they'll add actual product discovery in the future.
One additional benefit of a tool: you get insights into discussions other PMs have with customers. It's good to be aware of requirements customers have on your product area that they may have communicated to other PMs working on other parts of the product.
To do this you need complete observability of all customer interactions, i.e., meeting/call notes, presales notes, forum posts, zendesk support tickets, services interactions, etc. Productboard goes quite far in enabling you to bring all these channels together so you can build a data driven roadmap. Jira Product Discovery on the other hand is quite thin on this, more focussed on handover to the development teams, showing roadmaps, and tracking progress. Hopefully they'll add actual product discovery in the future.
One additional benefit of a tool: you get insights into discussions other PMs have with customers. It's good to be aware of requirements customers have on your product area that they may have communicated to other PMs working on other parts of the product.
Sure but I mean does that result in different outcomes compared to identifying and focusing on the next most important few things which will move the needle at any given time, which tend to be quite obvious? GitLab for example built a billion dollar company by for the most part incrementally focusing on the next most important step, without deep data-driven backlog analysis or trying to capture all interactions and contexts related to potential product feature discussions. https://handbook.gitlab.com/handbook/values/#iteration
Probably depends on your stakeholders. In a small company with owners (having domain knowledge and experience) driving the roadmap there's probably no need to provide data for what should be the next important thing. In a large corporation however where a PM needs to convince higher level (MBA type) stakeholders about product prioritization, having data goes a long way to convince stakeholders.
Yeah, that's fair. I think GitLab avoided that by not having MBA-types approving the roadmap.
If you want to automate the "make a note" and "break down into needs and wishes" part you can use https://www.getcustomeriq.com/
I appreciate the sentiment here, but this is not my experience. I talk to our customers almost every day, and for this reason, we have all kinds of well-vetted features and improvements in our backlog. There's always more to do than you have time for; the difference is whether or not your backlog is directly informed and refined by customer feedback.
Author here. Appreciate your perspective. I find large backlogs get stale quickly, and what was important three months ago is often not the case as context has changed. If I have a good ear to the ground I've discovered that there's usually something more valuable that can be delivered, and the way I've discovered is through talking to people.
Your point about "directly informed and refined by customer feedback" is well-taken, but in my experience a large backlog is rarely that, but more a dumping ground that seems daunting. Of course it depends on who is managing it and how, but more often than not I've seen PMs succumb to big backlogs rather than make it a well-vetted list maintained proactively like you have stated.
Your point about "directly informed and refined by customer feedback" is well-taken, but in my experience a large backlog is rarely that, but more a dumping ground that seems daunting. Of course it depends on who is managing it and how, but more often than not I've seen PMs succumb to big backlogs rather than make it a well-vetted list maintained proactively like you have stated.
That's fair enough I think! I totally agree that larger backlogs tend toward staleness. Just like a good shrub, they need care, feeding, and trimming :)
By the way, I enjoyed the article! It's a good share, and appreciate the perspective.
By the way, I enjoyed the article! It's a good share, and appreciate the perspective.
I think the key is that the more vague and further out the ideas, the fewer details we should try to capture.
Dumping details into something that we can’t understand yet seems like it smacks of a way to manage anxiety. Kind of like an inverse form of procrastination.
It’s easy to believe that we can just think our way out of problems, but sometimes we need to build small things, solicit feedback and iterate. And that can be uncomfortable if there’s something impeding that.
Dumping details into something that we can’t understand yet seems like it smacks of a way to manage anxiety. Kind of like an inverse form of procrastination.
It’s easy to believe that we can just think our way out of problems, but sometimes we need to build small things, solicit feedback and iterate. And that can be uncomfortable if there’s something impeding that.
Yeah I'm not sure I follow the logic here. The only reason I have anything to work on at all is because we've talked to customers.
I think maybe the implication is that if your backlog is big, it's a "smell" that you're over-planning. I don't think that's true, but I guess the sentiment is good.
I think maybe the implication is that if your backlog is big, it's a "smell" that you're over-planning. I don't think that's true, but I guess the sentiment is good.
> How you think people use your app is different than how they use it
>
> Make it a point to observe the customer when they are using your app. ...
> You can track all the metrics you want, but there’s something surreal about seeing a user scroll up and down trying to find something, hitting the back button, waiting, trying to click something that isn’t clickable etc.
I wish Apple, Google, and every other company on the planet did this. Every Single Day, Multiple Times A Day, I run into UI issues in software (and non-software) that IMO would be mind numbingly obvious to fix if anyone had bother to actually watch a user. And, on top of not watching, it's often impossible to give feedback. Ever try to give Apple feedback? AFAICT it goes onto a black box, if you can find it. Google? They'll only take feedback in certain parts of their apps making it impossible to actually report an issue.
I wish Apple, Google, and every other company on the planet did this. Every Single Day, Multiple Times A Day, I run into UI issues in software (and non-software) that IMO would be mind numbingly obvious to fix if anyone had bother to actually watch a user. And, on top of not watching, it's often impossible to give feedback. Ever try to give Apple feedback? AFAICT it goes onto a black box, if you can find it. Google? They'll only take feedback in certain parts of their apps making it impossible to actually report an issue.
I jump on every opportunity I can to go out with support to a customer, just so I can see them using our software in action. I always come back with a list of pain points I'd never thought about.
As a technical person who's on the frontlines speaking to customers daily, I find this theory cute but it falls down on a few counts.
1. Recency bias & opportunity cost: When you're intentionally not working on a problem space given higher priorities, you still want to collect incoming feedback. This aids future work and if the feedback already exists, bump it up the priority list. When the team kicks off projects, you'll want to assemble as many data points and a core source will be scanning through your backlog.
2. Reactive development: If I chose to bypass the discipline of logging feedback (which I'd love to do from an energy conservation perspective), I'd find myself working on the most recent and lowest-hanging fruitful tasks, neglecting the broken windows that have long existed.
3. Team knowledgebase: If there's a single point of responsibility to collate feedback and deliver solutions, then I think the OP's point can stand as it's viscerally stored and probably just more efficient to have a fire and motion strategy.
When there's a team involved, there needs to be a shared corpus to asynchronously log and retrieve data points. Duplication is better than no data and can provide insights when written from different perspectives. There's no way about it, this backlog will quickly get big.
This can be taxing and messy but dealing with complex systems and people is messy. For well-oiled teams, it's necessary to have good housekeeping of your backlog. This includes archiving irrelevant tasks, de-duping tasks, regularly prioritising and ensuring you're making the best use of your tool.
What can be helpful for organization is to deem everything initially as "for consideration" and have a small "up next" & "bugs" column that should contain no more than 5 items each.
The tool itself is insignificant compared to good backlog maintenance.
What might be missing is a facade on top of your exhaustive backlog that surfaces comprehensible information that allows you to dive deeper (eg search, and see similar tickets) when necessary.
1. Recency bias & opportunity cost: When you're intentionally not working on a problem space given higher priorities, you still want to collect incoming feedback. This aids future work and if the feedback already exists, bump it up the priority list. When the team kicks off projects, you'll want to assemble as many data points and a core source will be scanning through your backlog.
2. Reactive development: If I chose to bypass the discipline of logging feedback (which I'd love to do from an energy conservation perspective), I'd find myself working on the most recent and lowest-hanging fruitful tasks, neglecting the broken windows that have long existed.
3. Team knowledgebase: If there's a single point of responsibility to collate feedback and deliver solutions, then I think the OP's point can stand as it's viscerally stored and probably just more efficient to have a fire and motion strategy.
When there's a team involved, there needs to be a shared corpus to asynchronously log and retrieve data points. Duplication is better than no data and can provide insights when written from different perspectives. There's no way about it, this backlog will quickly get big.
This can be taxing and messy but dealing with complex systems and people is messy. For well-oiled teams, it's necessary to have good housekeeping of your backlog. This includes archiving irrelevant tasks, de-duping tasks, regularly prioritising and ensuring you're making the best use of your tool.
What can be helpful for organization is to deem everything initially as "for consideration" and have a small "up next" & "bugs" column that should contain no more than 5 items each.
The tool itself is insignificant compared to good backlog maintenance.
What might be missing is a facade on top of your exhaustive backlog that surfaces comprehensible information that allows you to dive deeper (eg search, and see similar tickets) when necessary.
I think point 2 could be an advantage, not a downside. If no-one you speak to mentions the broken window, maybe it's not a big issue. This assumes you speak to a mix of old and new users
Most people don't report issues (apathy & bystander effect) therefore I put more value on those who take the time to do so.
> There is no point to having a large backlog because the bigger the backlog, the higher the unvalidated assumptions, and the lower the chance that it creates any customer value. I have made too many mistakes assuming that something is valuable, when nobody cares about it. A large backlog should be looked at with an extremely high degree of skepticism, as the size of your backlog is inversely proportional to how often you talk to customers.
This needs a gigantic "YMMV, depends on the type of product and customer, etc" attached to it.
I used to be the PM for a large and complex set of developer tools. The only reason a very large backlog would be filled with unvalidated assumptions is if someone filled the backlog with unvalidated assumptions.
In my experience, a very large backlog can also be filled with validated assumptions, and the way one does this is by talking to more customers.
I can understand an early-stage product having things in the backlog that are unvalidated that probably came from ideation and spitballing sessions in the early stages of planning.
But I would strongly disagree with the premise that "Backlog size is inversely proportional" is a reliable rule of thumb.
I agree that it is critical to make sure the things a team is building provide actual value and will benefit real customers. I think this would be better framed as "Talking to customers is critical to ensure you're building the right things".
This needs a gigantic "YMMV, depends on the type of product and customer, etc" attached to it.
I used to be the PM for a large and complex set of developer tools. The only reason a very large backlog would be filled with unvalidated assumptions is if someone filled the backlog with unvalidated assumptions.
In my experience, a very large backlog can also be filled with validated assumptions, and the way one does this is by talking to more customers.
I can understand an early-stage product having things in the backlog that are unvalidated that probably came from ideation and spitballing sessions in the early stages of planning.
But I would strongly disagree with the premise that "Backlog size is inversely proportional" is a reliable rule of thumb.
I agree that it is critical to make sure the things a team is building provide actual value and will benefit real customers. I think this would be better framed as "Talking to customers is critical to ensure you're building the right things".
Implement account spoofing
Account spoofing is a really easy way to test for issues in production, but it also means you have to trust your support and dev teams with production data. In some industries that is a huge problem for customers. The last startup I worked with gave devs no access to production data at all (customers were all large law firms who wouldn't have bought in of it meant giving access to data). This should really be seen as a last resort; it's much, much better from a security standpoint to work assuming you can't ever access customer data. Your software will be higher quality if you do.
Account spoofing is a really easy way to test for issues in production, but it also means you have to trust your support and dev teams with production data. In some industries that is a huge problem for customers. The last startup I worked with gave devs no access to production data at all (customers were all large law firms who wouldn't have bought in of it meant giving access to data). This should really be seen as a last resort; it's much, much better from a security standpoint to work assuming you can't ever access customer data. Your software will be higher quality if you do.
The support staff of a bank I'm customer of don't have a way to see the UI I'm using. I can understand that because how much money one has on an account could be quite sensitive: 100 Euro don't matter, 100 k is another matter and people can be bribed to report targets. Anyway, it took a very long time (months and calls) and randomly picking the right person in the call center before we understood that I could not change my street address because my contract (the "product" from their point of view) is very old and still has the "old" UI which doesn't allow for changes to the street address. Everybody I talked with assumed that I have the new UI, probably the only one they've been trained on, and they kept telling me "click here, click there, type the address in there". "Sorry, there is no input field, not even the menu." "Impossible."
If they had some sort of account spoofing they could have realized what was going on. In many apps there are no problems giving support staff full access to customer accounts. Furthermore, in many apps the team is so tiny that everybody could sit around the same table and that solves many issues with trust, even if everybody is working from home.
However the more you want hide from the support staff and the more it gets difficult to have a meaningful spoofing mechanism. Maybe the support staff might be fed random numbers instead of the actual amount of data, but even the number of operations on an account might be telling.
By the way, after I walked in the bank and made a person change my street address I'm still receiving some communications with the old address. Too many databases.
If they had some sort of account spoofing they could have realized what was going on. In many apps there are no problems giving support staff full access to customer accounts. Furthermore, in many apps the team is so tiny that everybody could sit around the same table and that solves many issues with trust, even if everybody is working from home.
However the more you want hide from the support staff and the more it gets difficult to have a meaningful spoofing mechanism. Maybe the support staff might be fed random numbers instead of the actual amount of data, but even the number of operations on an account might be telling.
By the way, after I walked in the bank and made a person change my street address I'm still receiving some communications with the old address. Too many databases.
In some industries, that's true and you can't even whisper about spoofing. In most industries, these risks can be mitigated by good quality logs and audits of what admins do when account spoofing is used. (I mean, good audits should be there anyway.)
> the size of your backlog is inversely proportional to how often you talk to customers
This doesn't track, at all.
The more you talk to customers, the more useless tickets for non-issues are created.
This doesn't track, at all.
The more you talk to customers, the more useless tickets for non-issues are created.
That's a definite risk. You really want to get a holistic understanding of customer's problem domain, where their pain is, plan for getting a pilot success and being able to parlay that to delivering much more value, etc.
What you don't want it one person going in, trying to play it as a salesperson, misunderstanding half of what is said, attaching too much weight to bikeshedding and random offhand remarks, not asking whys, almost mirroring everything customer says and promising to deliver it, etc.
Treating it as smarmy sales might be how an entrenched company that already has a semi-credible product can close some enterprise deals, but it's death for a startup that wants to understand the problems, and figure out a good solution they can build.
What you don't want it one person going in, trying to play it as a salesperson, misunderstanding half of what is said, attaching too much weight to bikeshedding and random offhand remarks, not asking whys, almost mirroring everything customer says and promising to deliver it, etc.
Treating it as smarmy sales might be how an entrenched company that already has a semi-credible product can close some enterprise deals, but it's death for a startup that wants to understand the problems, and figure out a good solution they can build.
Depends on how you have the conversations. If they are designed to uncover market-wide problems rather than single customer gripes, high value features will become obvious.
Product planning should always be done in a tree structure. The top nodes are business objectives, then under them are products, then under them are customer problems, then under them are backlog items. Saying you have too many backlog items typically means you don't have the proper structure set up, and probably also don't have a prioritized list of business objectives to work from.
"Talking to customers" is great for understanding customer problems, but know your business objectives first. Else you'll waste time gather feedback in areas you won't work on anyways.
"Talking to customers" is great for understanding customer problems, but know your business objectives first. Else you'll waste time gather feedback in areas you won't work on anyways.
A good search term for this is "opportunity-solution tree". Basically what you said, first you identify a business opportunity, then you customer-facing outcomes that would help you achieve the business opportunity, and THEN you identify solutions that help deliver those customer outcomes.
E.g. You discover a business opportunity to build a simpler confabulator. Step one is to identify the different possible outcomes for customers that would indicate you had successfully built something simpler. Identifying what that means is actually hard. Maybe lots of people say they want something simpler, but to some people that means "less data to manually input" and to other people it means "better guidance in the configuration process". So there's value in this step on its own - it helps clarify your thinking and gives you ways to know if you're successful. And THEN you can identify solutions to help achieve those customer outcomes. Maybe for the "better guidance" one you have possible solutions of improving the UI or integrating an LLM to answer questions. But since you've tied it to a real outcome for customers, you can do a better job evaluating those options.
It's hard work but the process does a much better job leading to coherent solutions vs. "bucket of features".
E.g. You discover a business opportunity to build a simpler confabulator. Step one is to identify the different possible outcomes for customers that would indicate you had successfully built something simpler. Identifying what that means is actually hard. Maybe lots of people say they want something simpler, but to some people that means "less data to manually input" and to other people it means "better guidance in the configuration process". So there's value in this step on its own - it helps clarify your thinking and gives you ways to know if you're successful. And THEN you can identify solutions to help achieve those customer outcomes. Maybe for the "better guidance" one you have possible solutions of improving the UI or integrating an LLM to answer questions. But since you've tied it to a real outcome for customers, you can do a better job evaluating those options.
It's hard work but the process does a much better job leading to coherent solutions vs. "bucket of features".
Backlog size is inversely proportional to how strong the product team is in your organization. More "No we aren't doing that idea" vs yes men.
If your backlog is massive, people aren't having hard conversations about what work will ACTUALLY get done in the next 12-18 months.
If your backlog is massive, people aren't having hard conversations about what work will ACTUALLY get done in the next 12-18 months.
"yes men" give a shit about the backlog or hard convos and just collect their paycheck?
Backlog tickets should have a cost range field and potential value range field.
Title: FizzBuzz copilot
Description: ...
Cost: $50,000-$150,000
Potential Value: $3000-$5000I've done this, though having even a range of numbers draws hyperfixation and scales poorly. Something relative (like $ = we could eat it and not blink but would rather not, $$$$ = this rescues the quarter) is enough.
I've always been a fan of the scale of "T-shirt size estimates"
In most cases it's almost impossible to quantify improvements in dollar amount like this except after the fact.
A lot of companies seem to forget they have a whole team, and sometimes more than one, whose whole job is to talk to customers.
Maybe you have one whose job is to convince new people to be customers. Maybe you have one who helps your customers with the parts of your product that are so broken or unintuitive that people have to ask a human for help when they get stuck. Maybe you have one whose job is to keep your customers happy enough to renew their contracts.
I can guarantee these people are frustrated up to their eyeballs that nobody gives any weight to the feedback they have about the product. Their whole job is to understand the customer experience, and feature development is planned by teams of people who don't even use the product themselves, never mind do they know how thousands of people use it.
You're sitting on a gold mine of insight about your customers. Ask the people you hired to talk to them what they need.
Maybe you have one whose job is to convince new people to be customers. Maybe you have one who helps your customers with the parts of your product that are so broken or unintuitive that people have to ask a human for help when they get stuck. Maybe you have one whose job is to keep your customers happy enough to renew their contracts.
I can guarantee these people are frustrated up to their eyeballs that nobody gives any weight to the feedback they have about the product. Their whole job is to understand the customer experience, and feature development is planned by teams of people who don't even use the product themselves, never mind do they know how thousands of people use it.
You're sitting on a gold mine of insight about your customers. Ask the people you hired to talk to them what they need.
Yes. And be sure to follow up with a robust customer interview to discover the why.
Executing a customer interview discovers the why behind feature requests.
If you leave it at the Sales and CS level you can end up with requests like I want to export to Excel. Sure, build that feature, but you risk missing the bigger picture.
Why does the customer want to do that? What’s their pain/problem/opportunity/JTBD?
You may uncover it is to integrate with another system, to give their boss a report, or to do some data analysis.
As a PM your job is to not build what customers are asking for, it is to solve the underlying need in line with your product vision and company strategy.
Executing a customer interview discovers the why behind feature requests.
If you leave it at the Sales and CS level you can end up with requests like I want to export to Excel. Sure, build that feature, but you risk missing the bigger picture.
Why does the customer want to do that? What’s their pain/problem/opportunity/JTBD?
You may uncover it is to integrate with another system, to give their boss a report, or to do some data analysis.
As a PM your job is to not build what customers are asking for, it is to solve the underlying need in line with your product vision and company strategy.
There's a big difference between "a customer asked for this once" and "people need actual human help to accomplish X, because it's not working nearly as well as we advertise it to work, and we're spending a huge chunk of our time compensating for a design flaw with human intervention."
I feel like there are some very precise ways to think about these things.
For example, a backlog is a priority queue. A priority queue can only be long if work is added more frequently than it is removed.
Work can be removed if it is either completed or abandoned.
Work can be added when users request features, users find bugs, product owners predict features will be useful, or the dev team adds technical improvements.
Talking to users will increase the bugs identified and the user requested features.
So by these relationships, talking to customers will directly increase the size of the backlog.
And the overall backlog length may be large due to many factors unrelated to talking to customers: slow development, never deleting out of date work, adding too many technical tasks, adding too much unvalidated vision work, etc.
Does anyone know of any books, blogs or youtubers that bring this kind of logical system level thinking to software work management?
For example, a backlog is a priority queue. A priority queue can only be long if work is added more frequently than it is removed.
Work can be removed if it is either completed or abandoned.
Work can be added when users request features, users find bugs, product owners predict features will be useful, or the dev team adds technical improvements.
Talking to users will increase the bugs identified and the user requested features.
So by these relationships, talking to customers will directly increase the size of the backlog.
And the overall backlog length may be large due to many factors unrelated to talking to customers: slow development, never deleting out of date work, adding too many technical tasks, adding too much unvalidated vision work, etc.
Does anyone know of any books, blogs or youtubers that bring this kind of logical system level thinking to software work management?
My experience has not been this. Backlog _size_ grows because engaged customers always want more features.
Backlog _priority_ gets smarter with customer input.
Backlog _priority_ gets smarter with customer input.
Theoretically, aren't PM's supposed to drive requirements based off customer input? I understand that doesn't happen always or even often, but I feel like this is well understood already and not some radical new concept.
I was thinking this might be talking about an early startup.
Founders have an initial product pitch and guess at what they have to build first, and they and any hires might have been stuffing tasks into the box, but they might still be trying to get prospective customers to talk with them.
There might be a bit of a Catch-22, if you need to have some ideas and/or something tangible before prospectives will talk with you, even if what you've thought of or done so far turns out not to be what they need.
Founders have an initial product pitch and guess at what they have to build first, and they and any hires might have been stuffing tasks into the box, but they might still be trying to get prospective customers to talk with them.
There might be a bit of a Catch-22, if you need to have some ideas and/or something tangible before prospectives will talk with you, even if what you've thought of or done so far turns out not to be what they need.
True. I worked for a startup where they got most of the way through their series A before they realized they built something no one wanted to buy. Guess what the only role they'd never filled was?
As a UX designer, the second point (Reduce time spent on UI design; focus on technical component design instead) is very, very dependent upon the first point (Replace planning time with talking to customers). Sure, you can put something out the door, but once it's out, how much followup with customers are you doing? There's a lot of places that talk a big game about how much they value UX, and then you get inside the org and that value is simply expecting a UX designer to carry out instructions, making them nothing more than a glorified graphics designer.
I worked at one company who, I feel, handled the UI/UX/Design/Development process about as correctly as I could imagine. It was unlike any other place I ever worked (and very successful at what they did).
They were a typical "we make products/digital experiences for brands/companies" kind of shop with some very big brands. Most companies their size that I worked for -- including one with extremely similar kinds of customers -- had about 100 employees, of them 70 developer/design/ui/ux, of those 70, 60 were developers, 10 were split amongst UX/UI/Design in different ratios depending on need.
At the company that did it right, half of the 70 were UX/UI/Design. Developers didn't get involved in the product until after project managers and UX had completed most of their work, Design/UI/Development would follow with development laying down the first line of code after everyone else is about 1/3 of the way through. Though we had fewer developers than any place I've ever worked at (even more stark considering the output was much more than we produced at other shops), we had the highest number of Senior/Dark Wizard developers than any place I've ever been, too. The polish of the products we produced was magnificent and we were well known for extremely well designed products. You saw many of them if you followed the second Obama election (those Surface large arcade-like tables were really popular that year -- my company did the app for at least one -- I think two -- of the 24-hour news channels) or bought a few major consumer brands.
This was also the only place I've ever worked with that regularly assembled test panels of customers for direct UX testing (we had someone on staff "that's all they did" was user studies of this nature) -- all paid for by the customer and the results were pretty incredible most of the time.
They were a typical "we make products/digital experiences for brands/companies" kind of shop with some very big brands. Most companies their size that I worked for -- including one with extremely similar kinds of customers -- had about 100 employees, of them 70 developer/design/ui/ux, of those 70, 60 were developers, 10 were split amongst UX/UI/Design in different ratios depending on need.
At the company that did it right, half of the 70 were UX/UI/Design. Developers didn't get involved in the product until after project managers and UX had completed most of their work, Design/UI/Development would follow with development laying down the first line of code after everyone else is about 1/3 of the way through. Though we had fewer developers than any place I've ever worked at (even more stark considering the output was much more than we produced at other shops), we had the highest number of Senior/Dark Wizard developers than any place I've ever been, too. The polish of the products we produced was magnificent and we were well known for extremely well designed products. You saw many of them if you followed the second Obama election (those Surface large arcade-like tables were really popular that year -- my company did the app for at least one -- I think two -- of the 24-hour news channels) or bought a few major consumer brands.
This was also the only place I've ever worked with that regularly assembled test panels of customers for direct UX testing (we had someone on staff "that's all they did" was user studies of this nature) -- all paid for by the customer and the results were pretty incredible most of the time.
>This was also the only place I've ever worked with that regularly assembled test panels of customers for direct UX testing (we had someone on staff "that's all they did" was user studies of this nature)
A dedicated UX researcher! What a rare creature, most UX teams have to fight tooth and nail to get one of those.
A dedicated UX researcher! What a rare creature, most UX teams have to fight tooth and nail to get one of those.
That's been my experience at every company I've been at. I don't know how they did it ... they not only got panels, they were all paid for by the customer. We had credentialed in house staff but routinely outsourced the work[0]. I asked how they sell these things so frequently and was told "it's easy" with no explanation.
The best I can tell is that the company was laid out specifically focused on industrial/product/digital design. It built excellent, polished products[1] and the clients that were attracted to the company wanted that polished product. We positioned ourselves as a partner in executing on that vision but the reality is that we were taking a few sentences of an idea and creating it (with a bunch of hostility from the partner along the way). If the client wanted the polished product, we gave them an RFP that included everything required to get there and many of the things on that RFP came from bruises we received from previous work, so we were ready with "Here's a perfect example of why that's a must-have." And some of these bruises were incredible: I know of at least one project that was over a year past-due owing to a customer's constant design adjustments.
They did a lot right. The design pricing and QA was double what I recall seeing at previous employers. Development cost (equating to time) was a bit more, on average, than previous employers[2]. The development budget didn't necessarily suffer due to design being too large, but we weren't consistent enough with change-orders to handle the fickle customers we often ended up with. Hiring was impossible -- to get the people necessary to build these products they had open positions in nearly everything and hired anyone who was exceptional whether or not they had work for them (we were paid salary). This sort of worked, but after losing a huge contract for a product in a language we wrote almost nothing else in, we took a 25% hit to staffing affecting everyone who specialized in that language exclusively. It was a very demanding job but I met some amazing people there -- I remember a certified genius hardware guy who when I asked about his experience learning "C++" he said "I learned from Bjarn Straustrup" -- delivered factually, deadpan, no hint/intention to brag -- so much so that I took it as "read the books/code/self-taught as he was an autodidact" but he clarified "my employer paid to have my team trained by him (I think in the 90s)." WTF?!
[0] You have to be careful, here -- we used a couple of providers and I can only remember Shiffrin Heyworth and I can't find them any longer. Shame, too, it's even harder to find these kinds of companies if you want to participate as a panelist (most are scams) -- they had real secret shopper programs, expert studies (flying panel participants with specific, narrow, subject matter expertise), 3-5 hour paid catered studies (with a 20% chance of being handed food/a cheque and sent on your way) -- all design/product/marketing focus -- it was a lot of fun.
[1] "Products" was a range, but mostly digital, however we did a few interiors of the early Microsoft stores. They spun off a few companies from products they partnered with third parties to design/develop, as well.
[2] Adjusting for "specialization tax" -- I worked for a company that wrote software add-ons for Skype for Business/Lync/etc ... there were very few of us ... my hourly billing rate made me wonder where my corner office on the top floor was hiding at. Though my dataset is small, it's still about twice what my time has been valued at to a third-party.
The best I can tell is that the company was laid out specifically focused on industrial/product/digital design. It built excellent, polished products[1] and the clients that were attracted to the company wanted that polished product. We positioned ourselves as a partner in executing on that vision but the reality is that we were taking a few sentences of an idea and creating it (with a bunch of hostility from the partner along the way). If the client wanted the polished product, we gave them an RFP that included everything required to get there and many of the things on that RFP came from bruises we received from previous work, so we were ready with "Here's a perfect example of why that's a must-have." And some of these bruises were incredible: I know of at least one project that was over a year past-due owing to a customer's constant design adjustments.
They did a lot right. The design pricing and QA was double what I recall seeing at previous employers. Development cost (equating to time) was a bit more, on average, than previous employers[2]. The development budget didn't necessarily suffer due to design being too large, but we weren't consistent enough with change-orders to handle the fickle customers we often ended up with. Hiring was impossible -- to get the people necessary to build these products they had open positions in nearly everything and hired anyone who was exceptional whether or not they had work for them (we were paid salary). This sort of worked, but after losing a huge contract for a product in a language we wrote almost nothing else in, we took a 25% hit to staffing affecting everyone who specialized in that language exclusively. It was a very demanding job but I met some amazing people there -- I remember a certified genius hardware guy who when I asked about his experience learning "C++" he said "I learned from Bjarn Straustrup" -- delivered factually, deadpan, no hint/intention to brag -- so much so that I took it as "read the books/code/self-taught as he was an autodidact" but he clarified "my employer paid to have my team trained by him (I think in the 90s)." WTF?!
[0] You have to be careful, here -- we used a couple of providers and I can only remember Shiffrin Heyworth and I can't find them any longer. Shame, too, it's even harder to find these kinds of companies if you want to participate as a panelist (most are scams) -- they had real secret shopper programs, expert studies (flying panel participants with specific, narrow, subject matter expertise), 3-5 hour paid catered studies (with a 20% chance of being handed food/a cheque and sent on your way) -- all design/product/marketing focus -- it was a lot of fun.
[1] "Products" was a range, but mostly digital, however we did a few interiors of the early Microsoft stores. They spun off a few companies from products they partnered with third parties to design/develop, as well.
[2] Adjusting for "specialization tax" -- I worked for a company that wrote software add-ons for Skype for Business/Lync/etc ... there were very few of us ... my hourly billing rate made me wonder where my corner office on the top floor was hiding at. Though my dataset is small, it's still about twice what my time has been valued at to a third-party.
> You may not be able to do all write operations while spoofing (e.g., updating payment methods), but most operations are read, and even the write ones are reversible. Don’t let this scare you, embrace it.
Yikes. I would not allow admins to change customer data in production by spoofing the user’s identity. There are too many ways for that to go wrong. Instead, copy the user data into a test environment and mess around with it there as much as you want.
Yikes. I would not allow admins to change customer data in production by spoofing the user’s identity. There are too many ways for that to go wrong. Instead, copy the user data into a test environment and mess around with it there as much as you want.
I've implemented this type of 'spoofing' system. Nothing happened. It was super valuable, both for the customers and the customer success team. Long as there is an audit log, things should be OK until a certain scale is reached.
Also most companies have a backoffice that should provide access to the information and possibility to apply actions to the state. So just giving access to this information in a more limited way that mimicks the customer's view is a no brainer for early-stage.
* Small company; two-sided marketplace with some hundreds of thousands on one side, and some tens of thousands on the other, so rather small scale.
Also most companies have a backoffice that should provide access to the information and possibility to apply actions to the state. So just giving access to this information in a more limited way that mimicks the customer's view is a no brainer for early-stage.
* Small company; two-sided marketplace with some hundreds of thousands on one side, and some tens of thousands on the other, so rather small scale.
I've worked in companies where it wasn't a thing and we were horribly ineffective at helping customers with complicated issues on our system.
It's my current predicament. I'm consulting for a 'serverless' startup that shuns away any sort of backoffice and / or impersonating. They also don't store logs, just what the infrastructure provider offers, so, a tail to live prod data.
It's just horrible to investigate a customer issue and is a frustrating experience both for the devs and the customers.
"Hello, <customer>, do you mind doing the exact same operation you were complaining about right now?", then it's shifting through microservice logging hell.
It's just horrible to investigate a customer issue and is a frustrating experience both for the devs and the customers.
"Hello, <customer>, do you mind doing the exact same operation you were complaining about right now?", then it's shifting through microservice logging hell.
Naive question here. I have always run as a small org or just me, on one or two self-contained products. But isn't there a standard view on separately logging two VERY different things? I.e. tracking of customer reported problems, vs. tracking of potential solution work?
#1. Customer reported problems/desires, with a focus on a particular customer's pain, their viewpoint on solutions, etc.
A long back log of #1 customer pain points makes sense to me, especially if you can link new ones to related old ones, and review them in order of urgency, recency, magnitude of customer pain and number of related incidents.
Groups of related pain points could even be triaged as rationale's for potential new adjacent products, as apposed to potential feature work. Without getting into any design work.
#2. Feature work tickets, filled out with rich info on what wide-spread or critical customer problem has been selected to be solved. How it fits into the business plan, product plan, development schedule and design plan etc.
This seems like a list that should be kept relatively small. A backlog of #2 feature to-do's suggest a lot of wasted initial/pre design work, on problems that never reached a critical level or product fit. Also designs without serious development plans quickly turn into useless busy work.
This separation also allows list #1 to be managed by customer relationship roles, and list #2 by product planning roles. With coordination as problems get prioritized for product planning treatment.
--
Spit balling and looking for feedback! I have not encountered this problem before, but am scaling up staff for a product suite with many more potential directions than we could built out without ruthlessly organized prioritization.
#1. Customer reported problems/desires, with a focus on a particular customer's pain, their viewpoint on solutions, etc.
A long back log of #1 customer pain points makes sense to me, especially if you can link new ones to related old ones, and review them in order of urgency, recency, magnitude of customer pain and number of related incidents.
Groups of related pain points could even be triaged as rationale's for potential new adjacent products, as apposed to potential feature work. Without getting into any design work.
#2. Feature work tickets, filled out with rich info on what wide-spread or critical customer problem has been selected to be solved. How it fits into the business plan, product plan, development schedule and design plan etc.
This seems like a list that should be kept relatively small. A backlog of #2 feature to-do's suggest a lot of wasted initial/pre design work, on problems that never reached a critical level or product fit. Also designs without serious development plans quickly turn into useless busy work.
This separation also allows list #1 to be managed by customer relationship roles, and list #2 by product planning roles. With coordination as problems get prioritized for product planning treatment.
--
Spit balling and looking for feedback! I have not encountered this problem before, but am scaling up staff for a product suite with many more potential directions than we could built out without ruthlessly organized prioritization.
Customers should inform you about problems they need solving, not how the problem will be solved by your software. It is your job to propose solutions (and this is often best done with a super simple prototype, not even in real software). They can feed back on your solution and it might be that 10% of users love your solution but there is a better solution out there for 90% of users. Implement the simplest of them and see if users want to use them.
When people can't even make features that make sense to users, generating ideas to go in the backlog is a terrible idea.
If you want to understand your users problems and how your product addresses them properly I cannot recommend the book Mental Models by Indi Young enough: https://www.amazon.com/Mental-Models-Aligning-Strategy-Behav...
When people can't even make features that make sense to users, generating ideas to go in the backlog is a terrible idea.
If you want to understand your users problems and how your product addresses them properly I cannot recommend the book Mental Models by Indi Young enough: https://www.amazon.com/Mental-Models-Aligning-Strategy-Behav...
[deleted]
You must not have sales people where you work
>focusing on keeping a smaller set of customers happy enough to recommend your product, over casting the net for a larger base of customers is turning out to be a sound strategic decision.
Both can be good, depending on what you wish. If you want to organically and steadily grow the company, you choose the former. If you want venture capital money and cash out fast, you choose the later.
Both can be good, depending on what you wish. If you want to organically and steadily grow the company, you choose the former. If you want venture capital money and cash out fast, you choose the later.
I've seen a lot of teams lately that are just making up a random workflow based on random ideas and whatever they feel like doing, and the managers say nothing. This doesn't lead to good product outcomes. Don't let your teams do whatever they want if you want good product outcomes.
>Small components and low-level reusability are key in UIs that are easy to change.
Not sure what he means by low level reusability? Instead of writing a high level component top to bottom, let's say a dialog, write some primitives that can be combined to build that high level component and others?
Not sure what he means by low level reusability? Instead of writing a high level component top to bottom, let's say a dialog, write some primitives that can be combined to build that high level component and others?
Account spoofing is a very double edged sword. I recommend building very careful audit controls and very clear user feedback indicating that you are logged in "as" someone else. I loathe working with products where privilege escalation is officially implemented via account spoofing. icky!
It's been fine when used as a tool for internal staff to resolve support issues. When the user reports they are seeing something funny on the page, you can go and see the page exactly as they see it without having to have their credentials. When it's given to the end users as a way to avoid having to build a proper permissions and sharing system, it's pretty gross.
As mentioned before in this thread, I've implemented this for an early stage startup with some hundreds of thousands of users. It was a game changer in terms of helping our customers with some processes, and us understanding the shortfalls of our UX.
On one hand, I have a backoffice that gives access to the staff to everything related to the customers, but on the other hand I'm supposed to believe that being able to 'impersonate' a customer is this highway to hell? As long as an audit log is held about who did what, this can go a long way forward.
Are you Series A? B? A decacorn? Sure, implement whatever distributed tracing dashboard analytics data lake serverless microservice monitoring solution you can dream of. But this is good advice for early stage.
On one hand, I have a backoffice that gives access to the staff to everything related to the customers, but on the other hand I'm supposed to believe that being able to 'impersonate' a customer is this highway to hell? As long as an audit log is held about who did what, this can go a long way forward.
Are you Series A? B? A decacorn? Sure, implement whatever distributed tracing dashboard analytics data lake serverless microservice monitoring solution you can dream of. But this is good advice for early stage.
Yes, but in an early stage software where engineers already have read/write to prod, account spoofing is so much better.
At a certain scale it needs to go away though, or be very tightly controlled/audited like you say.
At a certain scale it needs to go away though, or be very tightly controlled/audited like you say.
In addition to the audit controls, some kind of permission controls or model.
Not just the ACLs you've established internally for which personnel can do what, but ensuring that you have express permission of that particular customer to be looking at that particular data of theirs, on that occasion.
Not just the ACLs you've established internally for which personnel can do what, but ensuring that you have express permission of that particular customer to be looking at that particular data of theirs, on that occasion.
> If the user is reaching for the menu on page one, there’s something wrong with your UI.
- Looks at github... :-/
- Looks at github... :-/
Everyone hates Agile these days.
But if you go back to original Agile Manifesto, this article is really hitting a lot of the key principles.
Seems like Agile, or MVP, anything that someone writes down as some really valid bullet points, then grows into some consulting industry that ruins it.
But if you go back to original Agile Manifesto, this article is really hitting a lot of the key principles.
Seems like Agile, or MVP, anything that someone writes down as some really valid bullet points, then grows into some consulting industry that ruins it.
Idea: limit backlog size.
If something is going in, something's coming out, either to a sprint or deleted. And we can call it "Burn It To Ground" never to be brought up again. Or some process like that.
If something is going in, something's coming out, either to a sprint or deleted. And we can call it "Burn It To Ground" never to be brought up again. Or some process like that.
this is good startup advice.
I can feel the disagreements stirring amongst the HN crowd[0].
You know, this is an observation I've made sub-consciously a thousand times and I really appreciate you putting that into words. In my experience, frequent check-backs with the customer -- and planning those "detours of development to make something visible" or "prioritizing this with a fake back-end to make something visible" (which we may do anyway if we have front-end/back-end working simultaneously) -- I find the most useful parts of working this way have nothing to do with the usual Agile Suspects[1].
My observations come from the lens of being employed by a few companies where I was a Senior developer with one or two Mid/Junior levels designing all or a major part of a product for a third-party (usually IoT or fully digital product someone paid us to design/develop). This may not apply to "I make a SaaS product I sell to customers" because of the closeness of working with them, but some of them likely do:
(1) Willingness of the customer to engage in regular communication is (anecdotally -- my observed) biggest factor to success. Ya know what, sometimes it doesn't even matter, either. I did three jobs for an oil company everybody's heard of, paid for via consulting dollars given to them by Microsoft. They met with us about five times for three products with the vision being to roll out one of them to "every employee except for the clerks" and the rest back-end to the complete appropriate environment. All three were met with praise and brought us future work. Not one of the three was deployed beyond test capacity (of the something-ungodly-like "150,000 user licenses" they paid for, we logged all of ten, it was sad).
(2) If they are unwilling, or you suspect they are dis-engaged, meet with "your contact over at the company" and have an off-the-record (but you know it's not) careful conversation to discover the reason for the dis-engagement. We were straight-up told "Oh, no, they do this all the time. They have to spend the consulting dollars." Emphasis provided verbally but never explained. It was said as though it could have been finished off with "or they will be fired" -- despite that being absurd; that was the level of intensity. Sometimes, though, you find out that you're not listening (or in a larger forum, they're not willing to tell you what the elephant in the room is) and it might be the only opportunity you have to fix it. A past product I botched pretty well had this issue. I had a customer become disengaged on a product I was working -- up to the point of actually shopping the product to another company half-way through. There's a lot lost in the detail, but it came down to them paying us to develop a product with the assumption that they'd have total control over the layout of the data in the database (despite not mentioning it, nor it being specified in any useful way in our contract). Unfortunately, the product had about one way it could be laid out in the database -- and it wasn't a way this unsophisticated customer would be able to just run a few simple SELECT queries on. Or, that's what I thought the problem was. Once I rang up their "one terribly abused IT guy", and exchanged a few war stories from my work history, I said "What's up with Tom trying to force this ridiculous schema down our throat?" He laughed and said "The money they budgeted for the project covers everything except the admin tool and Tom knows he'll never grasp your Schema well enough to write it himself[2]." They'd been telling us they'd pay a second invoice for the Administration tool and this was confirmation that was out, which I'd already scoffed at but this was absolute confirmation. I wish I could say we did the right thing with the information and it all worked out but, unfortunately (and this was out of my control), nothing was done with it.
(3) Frequent communication leads to higher engagement which leads to the feeling of partial ownership. I saw this at two shops -- one where we had almost no competitors developing against the APIs we were experts at -- we were expensive, so customers became invested in the success of the final product. They were engaged because "if it failed, they might not have jobs." But the other shop was unique. We provided a service that, on the surface, looks a lot like a whole lot of other things, including things sold by Microsoft. But the product was designed targeting three, specific, narrow verticals. These verticals, for at least two huge brands, had nothing that really met their needs so our pitch was "we'll make a version of our product designed for your company with you." And we did. We responded to every little detail asked down to ensuring the buttons/other things looked like every other internal web app they used, branded in a manner that completely hid that it was a SaaS product we sold with another name or that there was another company involved. But we knew every single big brand had a department that does this even if they hire a whole other company to manage the majority of it. So we ensured the contracts allowed for us to re-brand and re-sell it to every one of their competitors (and because of the product, it ends up benefiting them if the other company is as successful as they are). Fast forward a few years, and those two companies have been purchased three times over, almost ended up becoming one, and each time the question of "Should we get rid of Super-App?" wasn't just "No", but met with stories from the department head of "How it was a short meeting after they heard from me and (the three other folks we built it with)." They continue to pay the yearly renewals and work with us to develop out more things every few months. We've re-done this with the other verticals to the point of "we've captured all of the low hanging fruit in that vertical" to "we are a very competitive product in that vertical" but where we're deployed, our customers love the product. Those early customers feel actual loss when people talk about replacing it because they feel like they had a part in its creation.
(4) Frequent communication means you actually understand what your customers are saying. The biggest problem with talking to customers is they ask for things that have nothing to do with what they want to accomplish. "Can I save that to a PDF file?" "Why?" "I want to print it in a consistent format?" "I can put a print button on the page that will do that?" Customers get hung up on specifics of what they want driven by limits of what they believe things can do. If I had a dollar for every time a customer was surprised it was easy to do something "that, I'm fairly certain I could make work in IE 6 with a little effort." That's not a "har har, the customer iz stupiDZ", it's "that's not their job", "that's mine." But they're trying to translate a little of what they're asking into "Software Development Shop" because to explain it to you in their language, you better know a whole lot about manufacturing headlight bulbs (or whatever), and you're trying to translate everything into headlight bulbs. Over time you understand each other's languages and know when to say "... wait a minute, are you trying to ...?" with results that work out a little better than Clippy.
[0] Let's pick the topics: "Anything in the category of project management, scrum, agile", and the "Customer's Don't Know What They Want" (aka Listening to the Customer Results in Features They Don't Use(tm)), the "Startup Advice Doesn't Apply Outside of Startups" ... but that has nothing to do with what I wanted to say.
[1] Building the product this way ensures that the customer and you are on the same page with what the end result should actually be. Nothing explains how it's going to work than a UI that kind of does some of the things the working thing will do.
[2] I did inquire why "internal IT Dynamo", who I knew was a programmer from outside circles, wasn't being forced to write it. He said "I told them I'd quit." It sucked because I was so proud of this design -- it performed brilliantly despite being 6th normal form for 3 tables and it actually had to be 6th normal form to do what I was trying to do. Even better, because it's such a bitch working with that data, I put instead of update/insert/delete triggers on a set of views so "if you wanted to screw with it in SQL Management Studio", go ahead, all enforced by simple constraints, 1/4 the code that was ultimately required by the customer's insisted-upon design but -- importantly -- didn't grow table data exponentially for every configuration added resulting in the whole system falling down after setting up about ten configurable products.
You know, this is an observation I've made sub-consciously a thousand times and I really appreciate you putting that into words. In my experience, frequent check-backs with the customer -- and planning those "detours of development to make something visible" or "prioritizing this with a fake back-end to make something visible" (which we may do anyway if we have front-end/back-end working simultaneously) -- I find the most useful parts of working this way have nothing to do with the usual Agile Suspects[1].
My observations come from the lens of being employed by a few companies where I was a Senior developer with one or two Mid/Junior levels designing all or a major part of a product for a third-party (usually IoT or fully digital product someone paid us to design/develop). This may not apply to "I make a SaaS product I sell to customers" because of the closeness of working with them, but some of them likely do:
(1) Willingness of the customer to engage in regular communication is (anecdotally -- my observed) biggest factor to success. Ya know what, sometimes it doesn't even matter, either. I did three jobs for an oil company everybody's heard of, paid for via consulting dollars given to them by Microsoft. They met with us about five times for three products with the vision being to roll out one of them to "every employee except for the clerks" and the rest back-end to the complete appropriate environment. All three were met with praise and brought us future work. Not one of the three was deployed beyond test capacity (of the something-ungodly-like "150,000 user licenses" they paid for, we logged all of ten, it was sad).
(2) If they are unwilling, or you suspect they are dis-engaged, meet with "your contact over at the company" and have an off-the-record (but you know it's not) careful conversation to discover the reason for the dis-engagement. We were straight-up told "Oh, no, they do this all the time. They have to spend the consulting dollars." Emphasis provided verbally but never explained. It was said as though it could have been finished off with "or they will be fired" -- despite that being absurd; that was the level of intensity. Sometimes, though, you find out that you're not listening (or in a larger forum, they're not willing to tell you what the elephant in the room is) and it might be the only opportunity you have to fix it. A past product I botched pretty well had this issue. I had a customer become disengaged on a product I was working -- up to the point of actually shopping the product to another company half-way through. There's a lot lost in the detail, but it came down to them paying us to develop a product with the assumption that they'd have total control over the layout of the data in the database (despite not mentioning it, nor it being specified in any useful way in our contract). Unfortunately, the product had about one way it could be laid out in the database -- and it wasn't a way this unsophisticated customer would be able to just run a few simple SELECT queries on. Or, that's what I thought the problem was. Once I rang up their "one terribly abused IT guy", and exchanged a few war stories from my work history, I said "What's up with Tom trying to force this ridiculous schema down our throat?" He laughed and said "The money they budgeted for the project covers everything except the admin tool and Tom knows he'll never grasp your Schema well enough to write it himself[2]." They'd been telling us they'd pay a second invoice for the Administration tool and this was confirmation that was out, which I'd already scoffed at but this was absolute confirmation. I wish I could say we did the right thing with the information and it all worked out but, unfortunately (and this was out of my control), nothing was done with it.
(3) Frequent communication leads to higher engagement which leads to the feeling of partial ownership. I saw this at two shops -- one where we had almost no competitors developing against the APIs we were experts at -- we were expensive, so customers became invested in the success of the final product. They were engaged because "if it failed, they might not have jobs." But the other shop was unique. We provided a service that, on the surface, looks a lot like a whole lot of other things, including things sold by Microsoft. But the product was designed targeting three, specific, narrow verticals. These verticals, for at least two huge brands, had nothing that really met their needs so our pitch was "we'll make a version of our product designed for your company with you." And we did. We responded to every little detail asked down to ensuring the buttons/other things looked like every other internal web app they used, branded in a manner that completely hid that it was a SaaS product we sold with another name or that there was another company involved. But we knew every single big brand had a department that does this even if they hire a whole other company to manage the majority of it. So we ensured the contracts allowed for us to re-brand and re-sell it to every one of their competitors (and because of the product, it ends up benefiting them if the other company is as successful as they are). Fast forward a few years, and those two companies have been purchased three times over, almost ended up becoming one, and each time the question of "Should we get rid of Super-App?" wasn't just "No", but met with stories from the department head of "How it was a short meeting after they heard from me and (the three other folks we built it with)." They continue to pay the yearly renewals and work with us to develop out more things every few months. We've re-done this with the other verticals to the point of "we've captured all of the low hanging fruit in that vertical" to "we are a very competitive product in that vertical" but where we're deployed, our customers love the product. Those early customers feel actual loss when people talk about replacing it because they feel like they had a part in its creation.
(4) Frequent communication means you actually understand what your customers are saying. The biggest problem with talking to customers is they ask for things that have nothing to do with what they want to accomplish. "Can I save that to a PDF file?" "Why?" "I want to print it in a consistent format?" "I can put a print button on the page that will do that?" Customers get hung up on specifics of what they want driven by limits of what they believe things can do. If I had a dollar for every time a customer was surprised it was easy to do something "that, I'm fairly certain I could make work in IE 6 with a little effort." That's not a "har har, the customer iz stupiDZ", it's "that's not their job", "that's mine." But they're trying to translate a little of what they're asking into "Software Development Shop" because to explain it to you in their language, you better know a whole lot about manufacturing headlight bulbs (or whatever), and you're trying to translate everything into headlight bulbs. Over time you understand each other's languages and know when to say "... wait a minute, are you trying to ...?" with results that work out a little better than Clippy.
[0] Let's pick the topics: "Anything in the category of project management, scrum, agile", and the "Customer's Don't Know What They Want" (aka Listening to the Customer Results in Features They Don't Use(tm)), the "Startup Advice Doesn't Apply Outside of Startups" ... but that has nothing to do with what I wanted to say.
[1] Building the product this way ensures that the customer and you are on the same page with what the end result should actually be. Nothing explains how it's going to work than a UI that kind of does some of the things the working thing will do.
[2] I did inquire why "internal IT Dynamo", who I knew was a programmer from outside circles, wasn't being forced to write it. He said "I told them I'd quit." It sucked because I was so proud of this design -- it performed brilliantly despite being 6th normal form for 3 tables and it actually had to be 6th normal form to do what I was trying to do. Even better, because it's such a bitch working with that data, I put instead of update/insert/delete triggers on a set of views so "if you wanted to screw with it in SQL Management Studio", go ahead, all enforced by simple constraints, 1/4 the code that was ultimately required by the customer's insisted-upon design but -- importantly -- didn't grow table data exponentially for every configuration added resulting in the whole system falling down after setting up about ten configurable products.
>Instead of spending time planning and concocting roadmaps, replace that activity by talking to current or potential customers on how their lives can be improved, and letting that determine your next feature.
There are countless other articles claiming that customers don't know what they want. And that once you implement a feature they asked for, they aren't going to use it.
So, which way is it?
There are countless other articles claiming that customers don't know what they want. And that once you implement a feature they asked for, they aren't going to use it.
So, which way is it?
[deleted]
I hate the strategy of just taking every idea you hear and throwing it into a ticket. You just end up with this giant icebox of stuff you'll never do. If a big new prospect demands one of the ideas that's in the icebox be implemented immediately in order to close a deal, you're probably still not going to pull it out of the icebox, because you don't remember that it's there. Instead, you'll just create a new ticket for it, and eventually when going through the icebox, someone will go "hey, I think we built this already" and close as dupe.
Instead, I strongly prefer to have tickets that at least have some possibility of getting done in the short to medium term, and store other ideas elsewhere. Engineering keeps a list of tech debt that they'd like to address. PMs keep one list per project of possible improvements. For potential new features/products, they write PRDs but don't immediately turn them into a bunch of tickets.
Ultimately I think the giant backlog of stuff that mostly won't get addressed is a sign of weak PMs who are afraid to say no and like to fall back to the comfortable answer that is, "sounds interesting, I'll write a ticket for it."