Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

medium.com

Post reply on HN
Print view View original

11–20 of 31 posts

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#11

Post by daurnimator »

dkyc wrote: post #9
ukulele wrote: post #7

> Tip: Your marketing and sales teams should never be allowed to discuss features “in the pipeline” Probably unpopular here, but this is a misguided, engineer-centric view of a business. Sales & marketing should absolutely have some leeway on unreleased features, as they have very close relationships with customers and can get early feedback in the realest way possible: "Will the customer pay for it?" Cutting off thi…

I think this is meant in another way: sales and marketing should never discuss future features with potential customers . Meaning, they should not try to win deals by promising features not yet rolled out, rather than not being involved in internal priorization discussions. I happen to agree with the author to an extent. Selling future things rather than what's presently available makes sales a lot easier (which is w…

Contrarily, large customers often want to know what your roadmap is like: they want to be assured that your company/product is moving in the same direction that they are. Sales and marketing solve this by mentioning things in the pipeline. Without knowledge of what's coming up you'll fail to close a huge number of deals.

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#12

Post by ukulele »

dkyc wrote: post #9
ukulele wrote: post #7

> Tip: Your marketing and sales teams should never be allowed to discuss features “in the pipeline” Probably unpopular here, but this is a misguided, engineer-centric view of a business. Sales & marketing should absolutely have some leeway on unreleased features, as they have very close relationships with customers and can get early feedback in the realest way possible: "Will the customer pay for it?" Cutting off thi…

I think this is meant in another way: sales and marketing should never discuss future features with potential customers . Meaning, they should not try to win deals by promising features not yet rolled out, rather than not being involved in internal priorization discussions. I happen to agree with the author to an extent. Selling future things rather than what's presently available makes sales a lot easier (which is w…

This approach is cutting off a major strategic artery. Sales & marketing can do much more than just pushing what they're given; they should be a valuable pulse on the customer, and the truest feedback you can get for an upcoming feature is whether or not someone will pay you for it.

Particularly for larger or more advanced features, it makes much more sense to run engineering partly in parallel with sales & marketing (with feedback between the two) rather than in serial. Product and innovation cycles in the company are much tighter that way, and more accurate.

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#13

Post by ukulele »

pfarnsworth wrote: post #10
ukulele wrote: post #7

> Tip: Your marketing and sales teams should never be allowed to discuss features “in the pipeline” Probably unpopular here, but this is a misguided, engineer-centric view of a business. Sales & marketing should absolutely have some leeway on unreleased features, as they have very close relationships with customers and can get early feedback in the realest way possible: "Will the customer pay for it?" Cutting off thi…

No, I completely disagree. They should have input (ie. ability to make suggestions) but should no say. The Product Manager, who is in theory supposed to have all the metrics and has talked to all the customers, should be the one making the INFORMED decision based on DATA. Sales is motivated by making the sale. Period, end of story. They want the sale because it makes them money. There's nothing wrong with that becaus…

> They shouldn't be held to a feature because some salesperson promised it to a customer.

This is taking the most extreme end of the spectrum as a baseline, and suggesting the polar opposite (sales & marketing get no leeway) as a response. There are benefits in the middle of these two extremes, where you can have sales & marketing discussing potential features and also have a well defined strategy from PMs.

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#14

Post by mful »

> Do I want my team to value the number of tickets closed, or do I want them to value our critical business KPIs?

How does this look in practice, in large organizations? Is everyone empowered to freelance on whatever they think will improve said KPIs?

At some point, someone needs to have the power to decide what is being built (hopefully with an eye towards KPI-impact), and others need to fall in line and close some tickets.

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#16

Post by tarr11 »

After a while, I ran the same analysis I did before. The shopping cart abandonment rate was reduced by double digits: A difference worth more than $1 million dollars per month.

This is not a statistically valid way to test the effectiveness of your change.

For example, if you sell toys, and you run an analysis on the week before Christmas, then you make your code change, and then check again on the week after Christmas, you are going to have differences in customer behavior that have nothing to do with your change.

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#18

Post by rootusrootus »

tyfon wrote: post #4

At first I thought the ticket was going to be "stop using JIRA/Confluence". There is so much time wasted on this system where I work it's amazing. Some people sit all day updating JIRA with all kind of crap instead of actually doing their job. At this point I'm starting to get the same feeling towards it as towards SAP.

The most irritating thing I run into with JIRA is that every time our ALM team rolls out a new point release, things subtly change; behavior is a little different, controls moved around, etc. Normally I'm not one to get all bent out of shape when someone moves the cheese, but dang, every. single. release. things just move around for no apparent reason and I have to relearn how to do the exact same task.

Confluence is also evil. Not because it's Atlassian, but because wikis have many downsides to go along with the upsides. Everyone can create their own pages, so ... they do. And they don't keep maintaining it. So the amount of "documentation" we have is ever increasing and out of date. And like you say, a few people seem to do nothing but confluence work all day long.

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#19

Post by minimaxir »

tarr11 wrote: post #16

After a while, I ran the same analysis I did before. The shopping cart abandonment rate was reduced by double digits: A difference worth more than $1 million dollars per month. This is not a statistically valid way to test the effectiveness of your change. For example, if you sell toys, and you run an analysis on the week before Christmas, then you make your code change, and then check again on the week after Christm…

It also depends on how long "a while" is.

Re: How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter

#20

Post by taeric »

bdcravens wrote: post #8
tyfon wrote: post #4

At first I thought the ticket was going to be "stop using JIRA/Confluence". There is so much time wasted on this system where I work it's amazing. Some people sit all day updating JIRA with all kind of crap instead of actually doing their job. At this point I'm starting to get the same feeling towards it as towards SAP.

I think Jira's knobs and settings can get in the way, but I've found it to be fairly effective when used in a focused way (and recent updates seem to have optimized for that)

Like any tool for managing the health of something, it all depends on the quality of the data in the system.

What I have not seen, is evidence that it helps improve the data. So, if you have someone that is good at keeping the data healthy, they can make the tool look amazing. The tool doesn't really help people get there, though.

I don't think there is a universal answer here, yet. :(

I would love to be proven wrong.

Post reply on HN