[HN Gopher] Backlog size is inversely proportional to how often ...
___________________________________________________________________
Backlog size is inversely proportional to how often we talk to
customers
Author : recroad
Score : 343 points
Date : 2024-01-21 19:18 UTC (2 days ago)
(HTM) web link (bitbytebit.substack.com)
(TXT) w3m dump (bitbytebit.substack.com)
| JohnMakin wrote:
| 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.
| neilv wrote:
| 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.
| JohnMakin wrote:
| 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?
| bonecrusher2102 wrote:
| 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.
| nerdponx wrote:
| 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.
| recroad wrote:
| 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.
| bonecrusher2102 wrote:
| 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.
| switchbak wrote:
| 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.
| xyzzy123 wrote:
| 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".
| idopmstuff wrote:
| > 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.
| isoprophlex wrote:
| Oh man that cuts deep
|
| ---
|
| "Redo John's fix for frobulator service"
|
| Definition of done: The fix is implemented correctly.
| xyzzy123 wrote:
| Is it done or isn't it?
| isoprophlex wrote:
| We need another 5 refinement sessions
| Tommah wrote:
| 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."
| esafak wrote:
| You should have just periodically flushed old tickets.
| Everybody would have been happy, and none the wiser :)
| nolongerthere wrote:
| That is so toxic and just painful to read. Hard to understand
| how people function like that.
| denkmoon wrote:
| 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.
| winrid wrote:
| I don't understand what full means. It is weird being at a
| place long enough to see ticket 1 and ticket 60k, though.
| nicoburns wrote:
| 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).
| adrianN wrote:
| If you're still at five digit jiras the company must be
| very small.
| throwaway290 wrote:
| And sometimes new and old PM is future & past versions of the
| same person!
| cmcconomy wrote:
| 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!
| nathancahill wrote:
| 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.
| neilv wrote:
| 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.
| Gigachad wrote:
| 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.
| ThalesX wrote:
| 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.
| 2024throwaway wrote:
| > 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.
| mindok wrote:
| 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.
| neilv wrote:
| 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.
| idopmstuff wrote:
| In my experience, this depends a lot on how you organize possible
| features/improvements/etc.
|
| 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."
| alexanderchr wrote:
| Very similar to what's recommended in Basecamp's Shapeup book:
|
| https://basecamp.com/shapeup/2.1-chapter-07
| hakunin wrote:
| 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.
| roenxi wrote:
| 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.
| idopmstuff wrote:
| > 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.
| danielmarkbruce wrote:
| 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?
| AndrewKemendo wrote:
| 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.
| milesskorpen wrote:
| 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.
| esafak wrote:
| 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?
| milesskorpen wrote:
| 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.
| nolongerthere wrote:
| 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.
| kqr wrote:
| 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.
| andreasmetsala wrote:
| > 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?
| nicoburns wrote:
| 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.
| danielmarkbruce wrote:
| 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.
| gherkinnn wrote:
| Drop those ideas. Ideas are cheap. If it relevant in two
| year's time it will resurface naturally.
| danielmarkbruce wrote:
| 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.
| jfoutz wrote:
| 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.
| IanCal wrote:
| > 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.
| idopmstuff wrote:
| > 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.
| peebeebee wrote:
| 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.
| idopmstuff wrote:
| 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).
| bhaney wrote:
| And that problem somehow goes away if you store that same
| information in a separate system?
| xboxnolifes wrote:
| 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.
| peebeebee wrote:
| 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.
| fourthark wrote:
| Yes, because you just don't look at the list at all.
| IanCal wrote:
| Which is fine, you can then save even more effort by
| never writing them down at all.
| morgante wrote:
| 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.
| nicoburns wrote:
| They don't need to be in principal. But in practice I've
| yet to find a tool that does both things well.
| IanCal wrote:
| 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.
| nicoburns wrote:
| > 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.
| mcny wrote:
| 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?
| pc86 wrote:
| 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.
| nicoburns wrote:
| > 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.
| nicoburns wrote:
| > 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.
| eviks wrote:
| 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
| IanCal wrote:
| 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_?
| eviks wrote:
| 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
| IanCal wrote:
| > 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?
| PeterisP wrote:
| 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".
| IanCal wrote:
| > 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.
| doix wrote:
| 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.
| 9dev wrote:
| 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.
| halgir wrote:
| Where do you keep those to avoid cluttering the "real"
| backlog? Separate Jira (if applicable) project?
| cocoflunchy wrote:
| There are products for those like
| https://www.productboard.com/ or https://harvestr.io/
| SigKill9 wrote:
| 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 :)
| perlgeek wrote:
| 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).
| johnobrien1010 wrote:
| 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.)
| jm547ster wrote:
| Jira service desk to a separate backlog which is reviewed
| and filtered.
| Gormo wrote:
| 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.
| doix wrote:
| 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.
| datadrivenangel wrote:
| 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.
| atoav wrote:
| 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.
| kqr wrote:
| 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.
| hurril wrote:
| 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!)
| MrGilbert wrote:
| 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.
| bertil wrote:
| Wouldn't a curated version of the icebox help notice that
| pattern early? Especially if the team changes quite fast.
| hurril wrote:
| 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.
| RHSman2 wrote:
| 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.
| frereubu wrote:
| 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.
| Lutger wrote:
| > ...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.
| bertil wrote:
| 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.
| Perepiska wrote:
| 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.
| kevincox wrote:
| 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.
| anonyfox wrote:
| 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!
| skydhash wrote:
| 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.
| MetaWhirledPeas wrote:
| 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."
| mooreds wrote:
| 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%...
| idopmstuff wrote:
| I see your product is for devs, so totally get this. I work
| in enterprise software and can't imagine this would work
| well.
| mooreds wrote:
| 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 :).
| goodlinks wrote:
| Vote = vote * employee.grade
|
| (/S this isnt actually a good idea but may be practical
| depending on the org)
| SkyBelow wrote:
| 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)
| goodlinks wrote:
| 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.
| sparrowInHand wrote:
| 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.
| bcoughlan wrote:
| 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.
| rogerkirkness wrote:
| The best products tend to have PMs willing to say No the
| most, though.
| nradov wrote:
| 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.
| z3ugma wrote:
| My experience has not been this. Backlog _size_ grows because
| engaged customers always want more features.
|
| Backlog _priority_ gets smarter with customer input.
| haswell wrote:
| > 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".
| hkon wrote:
| You must not have sales people where you work
| bearjaws wrote:
| 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.
| geraldhh wrote:
| "yes men" give a shit about the backlog or hard convos and just
| collect their paycheck?
| snarfy wrote:
| 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-$5000
| eddythompson80 wrote:
| In most cases it's almost impossible to quantify improvements
| in dollar amount like this except after the fact.
| starkparker wrote:
| I'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.
| marcod wrote:
| I've always been a fan of the scale of "T-shirt size
| estimates"
| munchler wrote:
| > 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.
| ThalesX wrote:
| 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.
| marcod wrote:
| 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.
| ThalesX wrote:
| 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.
| efitz wrote:
| 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.
| mdip wrote:
| > Every team I've worked on that maintains a backlog, got most
| of their backlog from customers.
|
| I'm not completely disagreeing with you as this has been my
| experience, in the past, too. Here's how it's usually worked if
| it's taken long-term. Initially, if it's been a while, oh man:
| the backlog _explodes_. But more likely, you 're in a place
| like me where you check in with your customers at somewhat
| regular intervals and, maybe, you know when "Bob's Widgets" is
| going to be checked in with because every time you call Bob, he
| reads you a ten page list of tiny little fscking details that
| make you want to reach through the phone and tell Bob there are
| _other_ customers waiting on _Heart Transplants_ and his little
| paper cut can wait.
|
| 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" :)
| eszed wrote:
| 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.
| efitz wrote:
| 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.
| smeej wrote:
| 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.
| drsim wrote:
| 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.
| smeej wrote:
| 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."
| lucidguppy wrote:
| > If the user is reaching for the menu on page one, there's
| something wrong with your UI.
|
| - Looks at github... :-/
| Nevermark wrote:
| 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.
| GenerWork wrote:
| 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.
| mdip wrote:
| 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.
| GenerWork wrote:
| >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.
| mdip wrote:
| 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.
| throwawaaarrgh wrote:
| 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.
| ako wrote:
| 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.
| j4yav wrote:
| 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?
| ako wrote:
| 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.
| j4yav wrote:
| 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
| ako wrote:
| 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.
| j4yav wrote:
| Yeah, that's fair. I think GitLab avoided that by not
| having MBA-types approving the roadmap.
| nox101 wrote:
| > 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.
| magicalhippo wrote:
| 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.
| onion2k wrote:
| _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.
| laserbeam wrote:
| 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.)
| pmontra wrote:
| 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.
| DeathArrow wrote:
| >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?
| DeathArrow wrote:
| >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?
| DeathArrow wrote:
| >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.
| chris_nielsen wrote:
| 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?
| kulor wrote:
| 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.
| jerrre wrote:
| 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
| kulor wrote:
| Most people don't report issues (apathy & bystander effect)
| therefore I put more value on those who take the time to do
| so.
| andy_ppp wrote:
| 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...
| FrustratedMonky wrote:
| 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.
| EmilStenstrom wrote:
| 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.
| mason55 wrote:
| 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".
| andirk wrote:
| 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.
___________________________________________________________________
(page generated 2024-01-23 23:02 UTC)