This may sound crazy, but I'm OK with a request falling through the cracks if it was not important enough for the requester to follow up with me.
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 may sound crazy, but I'm OK with a request falling through the cracks if it was not important enough for the requester to follow up with me.
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.
> I'm OK with a request falling through the cracks if it was not important enough for the requester to follow up with me
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).
fair points all.
we are looking to address the overload through the prioritization so maybe that will somewhat address the first concern
I agree there are multiple use cases.
The value Loop gets with this level of access to user data will far outweigh any benefit they offer. No wonder they're giving it away for free. How much do you think users should be charging Loop for this data?
Precisely my concern. After knowing about loop I was intrigued and I was thinking of creating an account. I started the process with Gmail and I quickly stopped as soon as I've seen the scopes for which they ask to be authorized, for example edit/delete permissions on all my drive files. Not going to happen.
Awesome. I'm looking forward to trying this out. As a PM, I currently use Simplenote to jot down quick requests, or file it in JIRA if time allows. Eager to see if this turns me into a superhero.
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.
> Awesome. I'm looking forward to trying this out. As a PM, I currently use Simplenote to jot down quick requests, or file it in JIRA if time allows. Eager to see if this turns me into a superhero.
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.
Overwhelmed Project Managers to me implies poor processes - but we all seem to accept it.
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
Product managers shouldn't just be watching a product team execute, but planning integrations, negotiating buy in from other teams, and planning how future features/integrations can proceed.
> just don't do deadline driven projects and pretty much everything else falls into place
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).
Frankly there should be no need for a PM to do anything except in face of disaster -
I think this severely underestimates the importance of a PM role. Project management is like many other things, even if you don't think about it and put time into it you are doing it - just probably ineffectively.
>just don't do deadline driven projects and pretty much everything else falls into place
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".
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:
Is the data being sent to and processed at a third party? Many organizations won't allow users to use something that is going to send their emails off to third parties. I like the idea of it though.
How does FollowUp decide which question is important to me? (if at all)
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?
thanks for your questions
FollowUp is powered by the Loop HQ backend (loophq.com) and is in essence the task extraction functionality broken out into a stand alone product.
1. when a user connects a platform (google for example), the Loop backend runs the metadata from the platform's content through its graph database to identify where does a specific email or file fit in to the user's world. based upon that analysis, Loop scores each contact and by association, each content item with a "Loopscore" which determines the relative importance of that contact or content. this is a continuously iterative process and is impacted by the user's continued behavior.
2. I refer you to our privacy policy which outlines the considerable protections and restrictions we have put on ourselves in order to safeguard user information https://loophq.com/privacypolicy
There's a 0% chance my current company nor any company I've worked for in the past is going to allow a third-party company to access our entire email and chat history. There are far too many instances of companies doing so with the intent to repackage and sell your data, or simply shoddy security on their side resulting in everything gets leaked.
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.
thank you for the feedback.
a couple of comments
1. if you use cloud based services (google, office365, slack etc) which are the only services we currently integrate, your company already allows a third-party to access your email and chat history.
2. depending on the circumstance, we are prepared to discus an on prem deployment and in fact are already involved in some of those discussions.
Curious if HNers involved in management of cloud providers like 365 and Gmail actually allow users to connect random cloud apps like this to their company mailboxes? The pitch here seems oddly user-oriented rather than directed at the enterprise.
Are companies actually allowing employees to exfil entire datasets to any company who comes around with an app and privacy policy?
all - thank you for submitting your comments.
couple of points
1. as per our privacy policy which I will make sure is live asap - - we do not share data with any third party and we do all the processing in house
2. the google privacy requirements are quite rigorous and we just went through a re-approval process under their new guidelines
3. thank you for identifying the typos...thought that was fixed
4. regarding formalizing the request process, our experience is that its difficult to mandate that a third party only use a certain channel and even if you do things slip through the cracks
I would be delighted to continue this conversation with any and all. thanks for your input.
on the third party front, it's _you_ who is the third party. My security team would have kittens if I were to link slack/email/anything to ya'll. I think that's what's at issue, not whether you then pass data outward (which, to be clear, would also be unacceptable)
Something about this is disturbing. Overwhelmed PMs are usually a sign of a larger structural issue regarding executive leadership or directionality. An app helps somewhat increase the volume of things that can be processed in such a rudderless structure is only going to compound the issue. In an organization where PMs aren't overwhelmed, this isn't going to be an issue.
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.
If an app helps a PM profess more feedback in the same time (efficiency), and helps a PM process more feedback than they otherwise would have because previously they forgot it (effectiveness), then that PM will be performing better.
It might help some PMs that were overwhelmed to no longer be overwhelmed.
interesting perspective
the overwhelmed PM is one instance of the bombardment with questions and requests from multiple sources.
this will not fix organizational issues but it should assist knowledge workers with staying on top of things to be done
This solves a real problem for anybody in a management role, including PMs.
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.
I think this problem is best solved by formalizing the request process. If you’re fielding requests in multiple channels and they are not landing in a queue you can sort and prioritize, you’re inviting chaos.
You will be amazed by even a formal request process can become chaos. At my current job, even with a request process and a ticketing system, requests are either being lost all the time or we need to deal with them immediately so they won't get lost.
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.
Scrolling the site with arrow keys is annoying and doesn't really work in Firefox (scroll to something: "I want to see that full line", website: "yeah nah, have the next section instead").
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.
[+] [-] codingdave|6 years ago|reply
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.
[+] [-] quanticle|6 years ago|reply
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.
[+] [-] Carpetsmoker|6 years ago|reply
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).
[+] [-] dvtrn|6 years ago|reply
Please come host a seminar with my product management group. Maybe if an outsider/third-party says it they'll actually listen.
[+] [-] gfragin|6 years ago|reply
[+] [-] bryanmillstein|6 years ago|reply
[+] [-] ghego1|6 years ago|reply
[+] [-] gfragin|6 years ago|reply
[+] [-] voldemort1968|6 years ago|reply
[+] [-] plexiglass|6 years ago|reply
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.
[+] [-] merlincorey|6 years ago|reply
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.
[+] [-] gfragin|6 years ago|reply
[+] [-] lifeisstillgood|6 years ago|reply
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
[+] [-] gibolt|6 years ago|reply
Building a product is a human process.
[+] [-] ignoramous|6 years ago|reply
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.
[0] https://news.ycombinator.com/item?id=20408514
[+] [-] ska|6 years ago|reply
[+] [-] k__|6 years ago|reply
The good one absorbed it, the bad ones kicked down.
[+] [-] rodolphoarruda|6 years ago|reply
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".
[+] [-] giancarlostoro|6 years ago|reply
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]
[0]: https://www.youtube.com/watch?v=SmHeP9Sve48
[+] [-] notJim|6 years ago|reply
[+] [-] notus|6 years ago|reply
[+] [-] gfragin|6 years ago|reply
[+] [-] shikharja|6 years ago|reply
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?
[+] [-] gfragin|6 years ago|reply
I would be happy to discuss further
[+] [-] meritt|6 years ago|reply
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.
[+] [-] gfragin|6 years ago|reply
[+] [-] loteck|6 years ago|reply
Are companies actually allowing employees to exfil entire datasets to any company who comes around with an app and privacy policy?
[+] [-] blowski|6 years ago|reply
[+] [-] gfragin|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] gfragin|6 years ago|reply
I would be delighted to continue this conversation with any and all. thanks for your input.
[+] [-] miker64|6 years ago|reply
[+] [-] yowlingcat|6 years ago|reply
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.
[+] [-] lukevdp|6 years ago|reply
It might help some PMs that were overwhelmed to no longer be overwhelmed.
[+] [-] gfragin|6 years ago|reply
[+] [-] brandonb|6 years ago|reply
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!
[+] [-] gfragin|6 years ago|reply
[+] [-] subpixel|6 years ago|reply
[+] [-] kostarelo|6 years ago|reply
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.
[+] [-] ma2rten|6 years ago|reply
[+] [-] Carpetsmoker|6 years ago|reply
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.
[+] [-] gfragin|6 years ago|reply
[+] [-] alectroem|6 years ago|reply
"FollowUp then looks for questions in messages and extracts them into a" .... something?
[+] [-] floatingatoll|6 years ago|reply
This may have been a soft launch that isn’t announced yet, given that the Privacy/Terms links aren’t links yet, too.
[+] [-] drudru11|6 years ago|reply
[+] [-] gfragin|6 years ago|reply