The most effective PMs I've worked under had a heavy filter on incoming requests, at least for established products, with "No" being the default answer. If multiple people started asking for the same thing multiple times, clearly it was important. But if you say yes to every little things that comes in via any channel, you end up with a complex, cluttered product.
I feel that a product like this is better applied to a customer services/support team, where you really do want to make sure every little complaint is addressed properly.
This sounds great in theory, but in practice it turns into an asshole filter (https://siderea.livejournal.com/1230660.html). In other words, what you've just done is create a set of incentives that reward the most obnoxious people with your attention, and starve those who politely wait. In time, those who politely wait will write you off as a flake, and then you'll wonder why everyone who contacts you obnoxiously sends three e-mails, four slack pings and an after hours text message for good measure.
The issue with this approach is that there will be a bias towards people who quickly/persistently follow up. Personally, I'm very hesitant to do so especially with busy people, as I don't want to add to their workload (or indeed, I dislike being pushy in general).
As a PM, you need to listen to your entire community, not one person. Whether they politely request something and wait, or whether they are excessively persistent, that is still just one request. And unless you only have a handful of customers, you need some consensus from the entire community that the request is a good one before saying "Yes", and getting to work on it.
Please come host a seminar with my product management group. Maybe if an outsider/third-party says it they'll actually listen.
Also, it's common to perceive that when these small requests fall through the cracks, its due to poor or lack of process or simply a bad PM! But I would argue that, just like processes breakdown with scaling companies, the same happens with PM's, just on a project level. Cognitive overload is real.
As a side note, a JIRA board full of random feature requests in my experience will generally become a patchwork graveyard of backlog feature requests with little to no coherent relationship or roadmap between them.
In my experience, when this occurs, it is then recognized that maintaining a roadmap and list of feature requests works better in a wiki or similar documentation-oriented space through which one can categorize and cross link the feature requests as needed, as well as keep track of information such as how often it has been requested, etc.
This allows for a clean separation between actual planned work that needs to get done and prospective planned work that may never get done, but we want to think about in the context of the rest of the work we may put in the system.
Agreed. The purpose of these "on the fly" tickets is to document the request in real-time, so it's not forgotten. It's critical to return to these tickets to add color and file them into the proper epic.
Frankly there should be no need for a PM to do anything except in face of disaster -
- plan the work - do the work - realise the pace of work won't hit the milestones at the dates predicted - ok - adjust
None of this needs a PM - just a few hours of a team lead. (ok so maybe that is a PM). but basically if you have one ticket system, and one set of milestones, you can see everything you need a Proiect manager for (need a ops manager or a dev lead or hiring lead - yes but no not project management)
just don't do deadline driven projects and pretty much everything else falls into place
Building a product is a human process.
Basecamp's Shape Up [0] talks abt fixed 6 week cycles for projects. Trim down projects to fit 6 weeks without compromise and not the other way around. Alternate engineers between heavy product development (6 weeks) and cool-down maintenance cycles (2 weeks).
A good read.
Frankly there should be no need for a PM to do anything except in face of disaster -
The good one absorbed it, the bad ones kicked down.
I've been doing PM work since 2002. I don't think you can work without deadlines -- plural -- in any kind of project for an established business these days. If you think you can, chances are the project is not that relevant/strategic/critical to the business after all. "It can wait".
Basically we need a project system that tells you, based on velocity and expected effort to complete (ie what you get from scrums) when your work will be complete - and if you don't like it you start to adjust.
Giving an estimate without getting all cards on the table. If you have never touched the tech before, and it's new to all your engineers, and you don't invest time into figuring out effort and limitations, you will miss your estimate entirely.
Having an experienced developer evaluate parts of the projects is a good way to gauge the feasibility ahead of time. I went from one job that did this, to one that didn't, I'm back at the former as a result. You can't estimate work on things you've never done with technology that was birthed just yesterday, or lacks an open / public community.
To those PM's that estimate blindly I just want to say:
Good luck, we're all counting on you.[0]
I'm concerned about the level of access required for this app before I try it out (I am a Product Manager). Sounds like you'd be reading through all my emails and PMs. Is that correct?
I would be happy to discuss further
If you want this to succeed with real companies, make it something we can host on-prem and lock down so we can manage the chain of custody, while still benefiting from your product.
I'd suggest, when trying to win over a technical community, you don't speak to us like we're completely ignorant. Those "third-parties" are the service providers themselves.
I'm going to trust Google and Slack a tiny bit more than LoopHQ's two employees (https://www.linkedin.com/company/loopscore/). And as neither of you have any technical experience whatsoever, this tells me you hired an outside team to build your products, which makes me question the on-going product quality, support, and security even more.
Are companies actually allowing employees to exfil entire datasets to any company who comes around with an app and privacy policy?
I would be delighted to continue this conversation with any and all. thanks for your input.
Creating software to solve organizational problems is a dangerously seductive illusion. At worst, it could be used as a surface level token fix to allow leadership to wash their hands of addressing a hard problem.
It might help some PMs that were overwhelmed to no longer be overwhelmed.
For requests that come in via email, techniques like Inbox Zero work pretty well--you can treat your email as a todo list, and as long as your inbox is empty, you know you didn't miss anything that your colleagues need from you.
But nowadays, many requests come in via Slack notifications. The problem is once you view the message, the notification disappears--so unless you explicitly have a very disciplined system to track requests as a separate to-do list, the default is for little things to fall through the cracks.
So nice tool!
I don't think is that simple. It needs proper design and someone on top to watch and pull the strings from time to time. At least in the beginning until this becomes the norm and people can pass it to new people without getting lost.
At any rate, does it come with a web verison? Because a mobile app for this is in instant no from me. If it does, it's not very clear from the website.
"FollowUp then looks for questions in messages and extracts them into a" .... something?
This may have been a soft launch that isn’t announced yet, given that the Privacy/Terms links aren’t links yet, too.
Highly recommend YC SuS for anyone looking to develop their ideas.