
How One Jira Ticket Made My Employer $1MM/Month: 7 Metrics That Actually Matter - stickhandle
https://medium.com/javascript-scene/how-one-jira-ticket-made-my-employer-1mm-month-7-metrics-that-actually-matter-ffb5b2376a6b
======
ukulele
> 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 this avenue is popular for engineers (myself included) but not
necessarily good for the long term health of a business.

~~~
dkyc
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 why reps
are often eager to do it), but the true value is created when sales sells what
is already there. My father always put it this way: _You have to sell what you
have_.

~~~
ukulele
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.

~~~
isostatic
Sure, but the conversation should be

Customer: "We want your product to do $FEATURE, there's nothing else that does
it / other products that do it have these problems" Sales: "Thanks, we'll have
a look at that and see if it's possible in the future"

or

When many customers want $FEATURE, it's something to consider

What shouldn't happen is

Sales: "Buy this product, it's great, and in the future it will have $FEATURE"
Customer: "Great, we want $FEATURE, when will it be ready"

------
tyfon
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.

~~~
bdcravens
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)

~~~
tetha
Our JIRA is kinda our external memory and our input for external teams.

For team members, it's easier and more effective to bob a post-it onto the
right white board and explain it during standup. Hosted JIRA is just
infuriatingly slow for that workflow, tbh.

For everyone else, yeah. Put in a JIRA ticket, one of us will put in
clarifications there. If it's something weird, we'll document steps there and
convert them into a runbook later. It's good enough for that.

------
tnolet
This post has nothing to do with tickets, Jira, Agile or actual in pocket
cash. It just says "do a usability test" some time before shipping.

------
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.

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

------
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.

~~~
foobarian
Well, presumably the tickets you have are there to build KPI-improving
features. The people who open the tickets open them for that purpose! At our
company even people who "freelance" stuff still open tickets for that work,
because it's useful to document stuff and help others learn.

------
justherefortart
The problem is in most businesses you can explain this until you're blue in
the face, to no avail.

------
foobaw
Interesting article - most of these metrics should be learned on the job for a
lot of product managers.

------
radley
Sounds like the team lacked a UX designer, probably as well an experienced
software product manager. Testing conversion rates is UX 101.

------
aaronbrethorst
tl;dr: be sure to usability test your products.

------
lloydde
2016

