Show HN: An app to help overwhelmed PMs never miss an important request(followup.loophq.com)
followup.loophq.com
Show HN: An app to help overwhelmed PMs never miss an important request
https://followup.loophq.com/
70 comments
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.
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 did not mean to give that impression. I clarified a bit in another comment, but I was not talking about rewarding people for poor behavior as much as avoiding taking all incoming requests as "To Be Done", simply because the request arrived.
> 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).
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).
That isn't what I meant. Admittedly, I can see why it was read that way, so let me clarify the larger point:
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.
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.
Or even worse you end up creating bullshit jobs which consist entirely of being a “follow upper”...
if you say yes to every little things that comes in via any channel, you end up with a complex, cluttered product.
Please come host a seminar with my product management group. Maybe if an outsider/third-party says it they'll actually listen.
Please come host a seminar with my product management group. Maybe if an outsider/third-party says it they'll actually listen.
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.
we totally understand the concerns and are hyper-vigilant about security and access to user information.
the permissions we ask to approve are the minimum and standard permissions required by the underlying cloud platform (google, office365, slack etc).
part of the loop functionality allows the user to interact with content that exists on the user's underlying platform i.e. read/reply/forward emails, open/access/edit files etc.
all of that is specific to the individual user, is protected through the encrypted credentials and token provided by the cloud platform upon oauth and governed by out privacy policy and terms of use.https://loophq.com/privacypolicy
Your candid and detailed responses here are much appreciated!
The product hits a lot of checkboxes for me as an overloaded project manager. If this ever turns into something self-hosted or (ideally) run-able directly from my workstation/phone without a cloud account, I would very likely give it a try! Best of luck.
The product hits a lot of checkboxes for me as an overloaded project manager. If this ever turns into something self-hosted or (ideally) run-able directly from my workstation/phone without a cloud account, I would very likely give it a try! Best of luck.
Thanks for the clarification! I'll keep an eye on loop :-)
"Free during open beta"
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.
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.
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.
> 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.
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.
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.
we hope we can help you be that superhero!
Jira is on our roadmap for future integrations
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
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.
Building a product is a human process.
Building a product is a human process.
> 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).
A good read.
[0] https://news.ycombinator.com/item?id=20408514
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
Frankly there should be no need for a PM to do anything except in face of disaster -
Most project managers I met were just the punching bags between customer and devs/designers.
The good one absorbed it, the bad ones kicked down.
The good one absorbed it, the bad ones kicked down.
Yes, they are the first sign that the company oversells its products/services. As soon as the customer realizes his expectations are not being met -- or never will be -- he starts punching the PM. Mature organizations would put Sales in project status calls to speak with the customer in the first sign of misaligned expectations, and that helps a bit.
>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".
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".
It takes the whole business to stop being deadline driven - and that is hard where exceptions are based on deadlines and upper management manages on exceptions
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.
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.
One thing that strikes me as foolish:
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
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
I took PM to mean product manager, not project manager.
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?
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
I would be happy to discuss further
I would be happy to discuss further
cool. it's good to see a little insight into how something like this works. but you kinda avoided the question by answering "refer to our privacy policy". we should be talking about how something like this works so it doesn't look shady when (not if) people find out after signing up. Of course you will be "reading" the emails and slack messages. How else would this know about the follow-up questions? I think it would be important to state that humans will not be reading those emails but algorithms will be scanning them to know how to help the PM. Not just read a lawyer speak privacy policy.
Point conceded.
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.
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.
> your company already allows a third-party to access your email and chat history
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.
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.
Many ATS tools like Workable already access your email history, so it's not so crazy to offer it. Many people will use and appreciate this service.
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?
Are companies actually allowing employees to exfil entire datasets to any company who comes around with an app and privacy policy?
the enterprise case is definitely a more involved sales cycle but so far quite a bit of interest
[deleted]
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.
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)
thanks miker64
our experience has actually not been that - and once security teams have had a chance to review there has been terrific acceptance.
we are only interacting with information that is already on a cloud platform and our protections, policies and structure look to build on that security not subvert it.
the common fear is that we would aggregate information and sell to third parties and that is dealt with in our privacy policies https://loophq.com/privacypolicy
I'm sure that will be the case for certain companies. For companies who routinely deal with PII, PCI, or other regulated data the security teams are likely to be much more worried about the potential for sensitive data to be inadvertently shared outside of the company. Even if it is communiques about only business sensitive matters (e.g., iPhone 12 XXL release) that is not something very security conscious companies will be happy having in the hands of a third-party without an appropriate security review.
Having run a security program at such a company, at the minimum I would expect a SOC 2 or ISO 27001 audit of your company before I would allow my company to utilize your services as it is tightly integrated to our internal communication platforms.
This isn't to say you need that now but you should understand there are segments of the potential customer base that will not work with you without being able to pass that level of scrutiny.
Having run a security program at such a company, at the minimum I would expect a SOC 2 or ISO 27001 audit of your company before I would allow my company to utilize your services as it is tightly integrated to our internal communication platforms.
This isn't to say you need that now but you should understand there are segments of the potential customer base that will not work with you without being able to pass that level of scrutiny.
absolutely right.
that is already on our radar given the types of customers we are currently talking to.
we are also seeing increased scrutiny from the API providers who are insisting on their own security audits to allow API access.
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.
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.
It might help some PMs that were overwhelmed to no longer be overwhelmed.
our thoughts exactly.
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.
So nice tool!
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!
thank you
I hope you will try it out.
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.
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.
Alternatively the person getting the request could put it in a queue.
That's still a "request process".
the thinking here is that if a PM is managing 3-4 projects with 5-8 people per project at any given time, there are potentially hundreds of questions/requests that come in per day. Yes - some come in through tickets but rare is the time that is so regimented.
just putting them on a list requires an assistant until now
until now
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.
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.
there is a web version at https://followup.loophq.com/ and just sign in at the top of the page.
or you can try the full product at https://www.loophq.com
Unrelated to the actual product, but there may be a typo or missing word on the website under "how it works" bullet 2
"FollowUp then looks for questions in messages and extracts them into a" .... something?
"FollowUp then looks for questions in messages and extracts them into a" .... something?
You may want to email them at [email protected] about that, in case they’re not looking here.
This may have been a soft launch that isn’t announced yet, given that the Privacy/Terms links aren’t links yet, too.
This may have been a soft launch that isn’t announced yet, given that the Privacy/Terms links aren’t links yet, too.
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.