<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: Why Bug Reports and Feature Requests Don’t Overwhelm Us Anymore	</title>
	<atom:link href="https://www.groovehq.com/blog/managing-bugs-and-feature-requests/feed" rel="self" type="application/rss+xml" />
	<link>https://www.groovehq.com/blog/managing-bugs-and-feature-requests</link>
	<description></description>
	<lastBuildDate>Thu, 24 Nov 2022 02:47:35 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=5.5.1</generator>
	<item>
		<title>
		By: Delzin		</title>
		<link>https://www.groovehq.com/blog/managing-bugs-and-feature-requests#comment-11558</link>

		<dc:creator><![CDATA[Delzin]]></dc:creator>
		<pubDate>Thu, 24 Nov 2022 02:47:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.groovehq.com/blog/?p=450#comment-11558</guid>

					<description><![CDATA[Same to you
&lt;b&gt;K.KONGBIAN.COM.CN/r5376TI&lt;/b&gt;]]></description>
			<content:encoded><![CDATA[<p>Same to you<br />
<b>K.KONGBIAN.COM.CN/r5376TI</b></p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Florian Rachel		</title>
		<link>https://www.groovehq.com/blog/managing-bugs-and-feature-requests#comment-7789</link>

		<dc:creator><![CDATA[Florian Rachel]]></dc:creator>
		<pubDate>Fri, 24 Apr 2020 09:20:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.groovehq.com/blog/?p=450#comment-7789</guid>

					<description><![CDATA[We had similar issues and on top of that there were huge communication problems between support (i.e. non-technical people) and engineering. We then tried to report bugs with Loom, which was already a step up and then migrated to Bird Eats Bug after one of the engineers found it. So far the experience has been good. Engineers said that they finally started getting good bug reports :D]]></description>
			<content:encoded><![CDATA[<p>We had similar issues and on top of that there were huge communication problems between support (i.e. non-technical people) and engineering. We then tried to report bugs with Loom, which was already a step up and then migrated to Bird Eats Bug after one of the engineers found it. So far the experience has been good. Engineers said that they finally started getting good bug reports 😀</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Roland Pokornyik		</title>
		<link>https://www.groovehq.com/blog/managing-bugs-and-feature-requests#comment-1203</link>

		<dc:creator><![CDATA[Roland Pokornyik]]></dc:creator>
		<pubDate>Wed, 16 Nov 2016 14:28:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.groovehq.com/blog/?p=450#comment-1203</guid>

					<description><![CDATA[How do you decide who&#039;s on bug duty? Is it something you built into every developers life? So let&#039;s say one day every week? or every two weeks each developer is on &quot;bug duty&quot;?]]></description>
			<content:encoded><![CDATA[<p>How do you decide who&#8217;s on bug duty? Is it something you built into every developers life? So let&#8217;s say one day every week? or every two weeks each developer is on &#8220;bug duty&#8221;?</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Hannah Chaplin		</title>
		<link>https://www.groovehq.com/blog/managing-bugs-and-feature-requests#comment-4636</link>

		<dc:creator><![CDATA[Hannah Chaplin]]></dc:creator>
		<pubDate>Thu, 22 Oct 2015 12:46:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.groovehq.com/blog/?p=450#comment-4636</guid>

					<description><![CDATA[We had this exact problem at our last SaaS business (B2B online &amp; stock management system) and ended up building https://receptive.io to solve it. There&#039;s a ton of great stuff for customers but we also map development effort against feature value so you can see which feature requests you should actually be building. 

Here&#039;s just a few of the problems we are solving with Receptive:

Measuring which requests come from the most valuable accounts
The big spreadsheet of requests never keeps up with this, or gets updated when users have churned.

Managing the “long tail” of small improvements
Every SaaS vendor knows the “big wins”, the top 3 missing features that are deal-breakers for many leads. We called them “embarrassing feature gaps”. The tough part is identifying the small fixes would make your customers happier without taking weeks of development effort.

The kid in the candy store problem
If you ask your customers, they would like almost everything from your backlog of feature ideas. You can’t act upon this feedback until your customer has prioritised. Un-prioritised lists of “wants” are almost worthless the product manager. We built a system to encourage customers to prioritise, which in many cases surfaces some surprisingly small features that make customers much happier.

Its so important to concentrate on what your paying customers want, to help you get to product/market fit as fast as possible. You need to filter out ideas from trial accounts and churned users, and consider those segments separately.

Keeping customers informed about new features that they actually care about. This involves a lot of searching back in emails etc, which is really time consuming and you are likely to miss someone.

Existing tools to handle customer feature requests are basically forums with “me too” voting. Great for transparency, and I&#039;m sure they help consumer brands to get feedback, but they don’t add a great deal of value for SaaS product managers. The product manager is the decision maker, SaaS businesses aren’t democracies.

Of course, we eat our own dog-food, using Receptive to handle feature suggestions from our own customers, which has been a great help, and an approach I’d recommend to anyone building a SaaS product, if you can do it.

Would love to get everyone&#039;s feedback on what we are doing.]]></description>
			<content:encoded><![CDATA[<p>We had this exact problem at our last SaaS business (B2B online &#038; stock management system) and ended up building <a href="https://receptive.io" rel="nofollow ugc">https://receptive.io</a> to solve it. There&#8217;s a ton of great stuff for customers but we also map development effort against feature value so you can see which feature requests you should actually be building. </p>
<p>Here&#8217;s just a few of the problems we are solving with Receptive:</p>
<p>Measuring which requests come from the most valuable accounts<br />
The big spreadsheet of requests never keeps up with this, or gets updated when users have churned.</p>
<p>Managing the “long tail” of small improvements<br />
Every SaaS vendor knows the “big wins”, the top 3 missing features that are deal-breakers for many leads. We called them “embarrassing feature gaps”. The tough part is identifying the small fixes would make your customers happier without taking weeks of development effort.</p>
<p>The kid in the candy store problem<br />
If you ask your customers, they would like almost everything from your backlog of feature ideas. You can’t act upon this feedback until your customer has prioritised. Un-prioritised lists of “wants” are almost worthless the product manager. We built a system to encourage customers to prioritise, which in many cases surfaces some surprisingly small features that make customers much happier.</p>
<p>Its so important to concentrate on what your paying customers want, to help you get to product/market fit as fast as possible. You need to filter out ideas from trial accounts and churned users, and consider those segments separately.</p>
<p>Keeping customers informed about new features that they actually care about. This involves a lot of searching back in emails etc, which is really time consuming and you are likely to miss someone.</p>
<p>Existing tools to handle customer feature requests are basically forums with “me too” voting. Great for transparency, and I&#8217;m sure they help consumer brands to get feedback, but they don’t add a great deal of value for SaaS product managers. The product manager is the decision maker, SaaS businesses aren’t democracies.</p>
<p>Of course, we eat our own dog-food, using Receptive to handle feature suggestions from our own customers, which has been a great help, and an approach I’d recommend to anyone building a SaaS product, if you can do it.</p>
<p>Would love to get everyone&#8217;s feedback on what we are doing.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Amrit Anandh		</title>
		<link>https://www.groovehq.com/blog/managing-bugs-and-feature-requests#comment-4659</link>

		<dc:creator><![CDATA[Amrit Anandh]]></dc:creator>
		<pubDate>Wed, 14 Oct 2015 12:18:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.groovehq.com/blog/?p=450#comment-4659</guid>

					<description><![CDATA[That&#039;s awesome Alex. That gives me a great insight into your workflow. This is important because we are working on an idea to automate this. Let me run it by you.

The basic idea is - when multiple users request the same feature or report the same bug, the recurrence will be automatically incremented rather than your &quot;gatekeeper&quot; having to do this manually at the end of the day. This way you have an idea of what to work on next. And since the bug or feature is linked to the ticket, your agents can update users once it&#039;s done.

Check it out and let me know your thoughts - http://pura.io/

We are integrating helpdesks with other tools like Pivotal Tracker, Trello etc.]]></description>
			<content:encoded><![CDATA[<p>That&#8217;s awesome Alex. That gives me a great insight into your workflow. This is important because we are working on an idea to automate this. Let me run it by you.</p>
<p>The basic idea is &#8211; when multiple users request the same feature or report the same bug, the recurrence will be automatically incremented rather than your &#8220;gatekeeper&#8221; having to do this manually at the end of the day. This way you have an idea of what to work on next. And since the bug or feature is linked to the ticket, your agents can update users once it&#8217;s done.</p>
<p>Check it out and let me know your thoughts &#8211; <a href="http://pura.io/" rel="nofollow ugc">http://pura.io/</a></p>
<p>We are integrating helpdesks with other tools like Pivotal Tracker, Trello etc.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Jack Ellis		</title>
		<link>https://www.groovehq.com/blog/managing-bugs-and-feature-requests#comment-3575</link>

		<dc:creator><![CDATA[Jack Ellis]]></dc:creator>
		<pubDate>Fri, 15 Aug 2014 14:13:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.groovehq.com/blog/?p=450#comment-3575</guid>

					<description><![CDATA[Great article, the use of images to highlight the process was especially helpful.]]></description>
			<content:encoded><![CDATA[<p>Great article, the use of images to highlight the process was especially helpful.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Kamil Rextin		</title>
		<link>https://www.groovehq.com/blog/managing-bugs-and-feature-requests#comment-3763</link>

		<dc:creator><![CDATA[Kamil Rextin]]></dc:creator>
		<pubDate>Fri, 13 Jun 2014 17:20:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.groovehq.com/blog/?p=450#comment-3763</guid>

					<description><![CDATA[Great post. I use Gmail Folders to keep track of everything and at the end of the week/month/day depending on volume input it into Trello and prioritize and start chugging away. For prioritization I have a simple formula: if the bug blocks someone from performing a core task in the app (one it is essentially meant to do or people do alot) then I drop everything and work on that. If not then I log it for later. 

As a free tool, we get a sh*t ton of one off requests like &#039;if only it did this&#039; and I have developed a system for this which may or may not be correct. I always ask  &#039;If you are willing to pay for $x for this, I&#039;ll give you a discount of 50% when we launch our premium version later this year&#039; for the most part - this works because if they are really serious about it, they&#039;ll pull up their credit card. Most of the time, it&#039;s a &#039;pie in the sky&#039; feature so it saves us time.]]></description>
			<content:encoded><![CDATA[<p>Great post. I use Gmail Folders to keep track of everything and at the end of the week/month/day depending on volume input it into Trello and prioritize and start chugging away. For prioritization I have a simple formula: if the bug blocks someone from performing a core task in the app (one it is essentially meant to do or people do alot) then I drop everything and work on that. If not then I log it for later. </p>
<p>As a free tool, we get a sh*t ton of one off requests like &#8216;if only it did this&#8217; and I have developed a system for this which may or may not be correct. I always ask  &#8216;If you are willing to pay for $x for this, I&#8217;ll give you a discount of 50% when we launch our premium version later this year&#8217; for the most part &#8211; this works because if they are really serious about it, they&#8217;ll pull up their credit card. Most of the time, it&#8217;s a &#8216;pie in the sky&#8217; feature so it saves us time.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Sahil Parikh		</title>
		<link>https://www.groovehq.com/blog/managing-bugs-and-feature-requests#comment-3779</link>

		<dc:creator><![CDATA[Sahil Parikh]]></dc:creator>
		<pubDate>Mon, 09 Jun 2014 08:53:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.groovehq.com/blog/?p=450#comment-3779</guid>

					<description><![CDATA[Fantastic post, Alex! At Brightpod.com we use our own app for bug tracking and feature development. Two things I noticed while planning - my team wanted a way to prioritize their tasks across all projects and also have the ability to focus on just a few of them every day/week. All the best!]]></description>
			<content:encoded><![CDATA[<p>Fantastic post, Alex! At Brightpod.com we use our own app for bug tracking and feature development. Two things I noticed while planning &#8211; my team wanted a way to prioritize their tasks across all projects and also have the ability to focus on just a few of them every day/week. All the best!</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Massimo Chieruzzi		</title>
		<link>https://www.groovehq.com/blog/managing-bugs-and-feature-requests#comment-3781</link>

		<dc:creator><![CDATA[Massimo Chieruzzi]]></dc:creator>
		<pubDate>Sat, 07 Jun 2014 18:42:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.groovehq.com/blog/?p=450#comment-3781</guid>

					<description><![CDATA[Great article Alex, at AdEspresso we&#039;re often struggling with the same problems.
For Feature request I really like a &quot;bidding&quot; method like the use used by Hubspot for example (through UserVoice):


- Users are directed to an idea board where they can insert new ideas or vote existing ones
- Each user is given a limited number of votes each month


This system usually avoid multiple requests for the same feature and allow our team to immediately identify which features are the most needed. The limited votes number per user prevent them from just upvoting everything and limit them to what they really need (they can also cast multiple &quot;votes&quot; to the same issue if they really need it.


Finally UserVoice allows us to update, both on web and via email, all the user who were interested in a feature about status changes.]]></description>
			<content:encoded><![CDATA[<p>Great article Alex, at AdEspresso we&#8217;re often struggling with the same problems.<br />
For Feature request I really like a &#8220;bidding&#8221; method like the use used by Hubspot for example (through UserVoice):</p>
<p>&#8211; Users are directed to an idea board where they can insert new ideas or vote existing ones<br />
&#8211; Each user is given a limited number of votes each month</p>
<p>This system usually avoid multiple requests for the same feature and allow our team to immediately identify which features are the most needed. The limited votes number per user prevent them from just upvoting everything and limit them to what they really need (they can also cast multiple &#8220;votes&#8221; to the same issue if they really need it.</p>
<p>Finally UserVoice allows us to update, both on web and via email, all the user who were interested in a feature about status changes.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Steve Thiel		</title>
		<link>https://www.groovehq.com/blog/managing-bugs-and-feature-requests#comment-3780</link>

		<dc:creator><![CDATA[Steve Thiel]]></dc:creator>
		<pubDate>Fri, 06 Jun 2014 21:09:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.groovehq.com/blog/?p=450#comment-3780</guid>

					<description><![CDATA[Alex, great article, and thank you. This is very timely for me as my product team is struggling with the same issues.

Your workflow paired with the &quot;seven questions to ask yourself before building a feature&quot; from Chapter 16 in Lean Analytics seems to solve most of my issues.

Alex, how do you prioritize feature requests, do you follow a checklist like this?

1. Why will it make things better?
2. Can you measure the effect of the feature?
3. How long will the feature take to build?
4. Will the feature overcomplicate things?
5. How much risk is there in this new feature?
6. How innovative is this new feature?
7. What do users say they want?]]></description>
			<content:encoded><![CDATA[<p>Alex, great article, and thank you. This is very timely for me as my product team is struggling with the same issues.</p>
<p>Your workflow paired with the &#8220;seven questions to ask yourself before building a feature&#8221; from Chapter 16 in Lean Analytics seems to solve most of my issues.</p>
<p>Alex, how do you prioritize feature requests, do you follow a checklist like this?</p>
<p>1. Why will it make things better?<br />
2. Can you measure the effect of the feature?<br />
3. How long will the feature take to build?<br />
4. Will the feature overcomplicate things?<br />
5. How much risk is there in this new feature?<br />
6. How innovative is this new feature?<br />
7. What do users say they want?</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Ryan Mattock (CommissionCrowd)		</title>
		<link>https://www.groovehq.com/blog/managing-bugs-and-feature-requests#comment-3782</link>

		<dc:creator><![CDATA[Ryan Mattock (CommissionCrowd)]]></dc:creator>
		<pubDate>Fri, 06 Jun 2014 19:33:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.groovehq.com/blog/?p=450#comment-3782</guid>

					<description><![CDATA[Another insightful post, thanks Alex! As a two sided Marketplace which connects self-employed sales agents and companies, we have two sides to concentrate on. Prioritising bug fixes as well as feature requests are something we are trying to prepare for prior to launch in June 2014. This helps immensely. Thanks again from the http://www.commissioncrowd.com team]]></description>
			<content:encoded><![CDATA[<p>Another insightful post, thanks Alex! As a two sided Marketplace which connects self-employed sales agents and companies, we have two sides to concentrate on. Prioritising bug fixes as well as feature requests are something we are trying to prepare for prior to launch in June 2014. This helps immensely. Thanks again from the <a href="http://www.commissioncrowd.com" rel="nofollow ugc">http://www.commissioncrowd.com</a> team</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
