"The most valuable commodity I know of is information."
rebelutionary / 2.0
Parenthood, Product Management and Pain
In spite of the six thousand manuals on child raising in the bookstores, child raising is still a dark continent and no one really knows anything. You just need a lot of love and luck - and, of course, courage. - Bill Cosby, Fatherhood, 1986
Being a parent is at once hard and rewarding. It's a part joy, part frustration and always a learning exercise.
I am one of the two parents of Atlassian, the father of the crazy idea that became JIRA and a guy who bleeds Atlassian blue every damn day.
Today is a tough day to be me.
Yesterday we closed the top voted JIRA issue for Field Level Permissions (FLP) as "Won't Fix", with a long explanation as to why that is so. We communicated that it will not be included in JIRA for the next 18 months. As we expected, there's been varying reactions from across our community - mostly in the form of flames from users who really wanted this feature.
I can assure you this was a very difficult parenting decision for us to make. It was not taken lightly.
I know how many people want FLP. I know what they want it for. I know how hard and complicated it is to build nicely because I've tried (find me another system with the queryability, flexibility of JIRA and an equivalent FLP system to what's above and I'll send you a signed t-shirt).
I do believe that despite the votes, we have made the right decision for our 8,500+ customers.
A Digression
We recently did a big internal exercise at Atlassian to articulate what our values were. I say articulate on purpose because values aren't something you go into a room and decide on. They're in the founders, they're in the early employees, they transmogrify themselves throughout the organisational DNA. You don't decide on values, you articulate them.
So what did we articulate as our 5 core values at Atlassian?
Well, I love 'em. They're heartfelt, they're irreverent, they're cheeky, they're bold, they are us.
Atlassian Values
- Open company. No bullshit.
- Build with heart and balance.
- Don't fuck the customer.
- Play, as a team.
- Be the change you seek.
I could explain any one of these values in a long blog post. We're open. We try to be upfront and straight forward. We try to make hard decisions being passionate and evenhanded to all parties. We put customers first, we stick together, we have fun and we're trying to change the world in our own way.
We ran a number of different exercises to try to draw out these values, for example - the Mars Group is roughly "Imagine you're recreating the company on Mars. You can only send 5 employees. Choose which 5 you would send. Why did you choose them? What values do they share or exhibit?".
We ran the exercises separately with our senior management team and with a group of employees from across the company. Both had to come up with 5 values they felt embodied the company.
The most fascinating (and gratifying as a founder) thing about it was the huge overlap between the two lists the teams came up with (which were merged to become the above). The correlation was scary, they were almost exactly the same list.
Fear not - the DNA runs strong in this building.
Taking Tough Decisions
Values are only worthless if they're just stuck on a wall. They should be embodied in every employee, in every new hire, in your products and in all the company's dealings.
So how does the decision to close FLP stack up against our values?
- We're being open. We just can't do it at the moment and we don't think it's the best way to deploy our limited engineering resources for the next year. We're copping the negative reactions on the chin - we offer you no BS and hope for none in return.
- This decision was not easy to come to, but it needed to be made - one way or the other. We considered all the possible outcomes and stakeholders.
- Isn't this decision screwing the customer because we're not delivering a feature they want? I don't believe so. As a product company, we need to take decisions about where to deploy our engineers, what to build for the benefit of the thousands of JIRA customers. By not pursuing FLP, I truly believe we will deliver more value over the next year to those customers in aggregate.
- We aren't having fun nor playing today. Being roasted by customers is never fun - trust me. My inbox is an ugly sight. I understand the frustrations being vented on the issue. That said, we are a team on this. Despite all the discussions, arguments and heated debate over the issue - I stand with Brett, Anton and all the others in the decision made.
- I'm not sure Gandhi ever knew what an issue tracker was but I can only guess as to whether he would have wanted FLP.
Where does all this leave the users who feel aggrieved? I hope they know that we are learning a lot from this issue. We're learning how to serve customers better, how to be the open company we want to be (trust me - being open is hard) and how to better communicate our decision making and direction.
Judge us on this - certainly - but judge us on all that JIRA is, not just JRA-1330.
Call The Fire Department
Amongst all the flames and anger, there is some balance - and I really would like to extend a thank you to those users, like Mike Brevoort:
Though I'm very disappointed and Atlassian shouldn't have let this drag on for this may years,* I applaud them for at least making a decision, a decision that in their opinion is in the best interest of the product*. How many times have you been strong armed to produce a feature that our constituants have choosen to not listen to the downstream consequences? Then six months later the same people are complaining about all of the things you warned them about. Just like parents, we need to make the best decisions for our children. Hopefully they made the best decision.
It's time to move on, re-raise your more specific issues and if Jira doesn't fit your need without this feature, go find another tool. Again, I applaud Atlassian for not falling into the be everything to everybody trap.
I couldn't have put it better if I'd written it myself. We should have made this decision earlier - I completely cop that.
JIRA is a 5 year old this year - a toddler. Many of our dreams for this little chap haven't been fulfilled yet. I'm really excited about the new features we have coming down the pipeline in the next year. I hope you'll be excited by them too.
And please remember that all this only happens because Atlassian is such an open company. Try to vote for features with Oracle or Microsoft or Sun any other large software company.
If we didn't let users vote on their issues, read each others comments, interact and scream at us - we wouldn't have this problem. Would that be a better place to be? Hell no. I still believe the gain to us and to customers from being open is far greater than the pain from publicly letting your customers down.
We're trying to be the best parents we can be. Time will tell.
Children begin by loving their parents; as they grow older they judge them; sometimes they forgive them. - Oscar Wilde
I hope this explains our thinking. As always, I welcome your feedback - the love and the flames.
Trackbacks
[JRA-1330] Field level security permissions
Guys - I'd like to personally say thanks for all your comments - the flames included. Nothing here is easy and we are listening. *I started writing a really long comment here, but it seemed better as a blog post so I've put it up on my personal blo...
Comments
You want open comments, here they are:
1. Yes, you are bullshitting the customers - this is very obvious
2. You have no balance and do not recognize what is important for 400+ enterprise customers
3. You fuck the customers since 4.5 years
It is evident that you are an intelligent guy, but we do not need a psychiatric treatment, we need the solution for our problems.
This is the begiining of the end for Atlassian, sorry - I liked you very much!
P.S. We certainly do not need your signed t-shirt - what for? Do you think that you are a movie star?
Mike,
Yeah, tough call. As I noted on the issue, I'd like to see Atlassian do some better damage control with a page or two describing some of the workarounds (state changes, changing vm templates etc) so we know what is possible right now.
If you want a product to compare with Jira for FLP, querying and flexibility take a look at ExtraView, another J2EE app but one that costs 10x Jira. FLP is standard with it, querying is better (IIRC) because I don't think it's using a limited form of Lucene. It doesn't have the flexibility of Jiras plugins, so I guess I don't get a tshirt - but that's ok because you never send me XXL ones anyway ;-)
Good luck with dealing with all the criticism.
~Matt
>Find me another system with the queryability, flexibility of JIRA and an equivalent FLP system to what's above and I'll send you a signed t-shirt
It's TrackStudio. But you learn it from Jira vs. TrackStudio comparison page.
Mike,
As JIRA customer and advocate in the company I work for, I must admit that the resolution of FLP feature somewhat shook me.
I think I really understand what kind of battle you had to fight to come up with such decision: JIRA developers, product management, marketing, support, finally you and Scott.
I must say I am disappointed that this feature will not be implemented in foreseeable future. At the same time, I must say I admire that you decided to stay honest to your customers and admit that you would not deliver this functionality.
There is one lesson learned in the whole story: you should have articulated this much earlier (probably at the time an initial release of JIRA 3.x was shipped and very core design decisions made implementation of FLP virtually impossible).
I hope that your customers will at least acknowledge one thing: they are not duped (as by many other companies selling “enterprise” stuff and promising various features “soon”) anymore. I hope that they don’t want to be.
For me Atlassian Values are one of the most valuable things in the company. I hope you will never ever give them up, but try to apply them or live according to them even harder.
Anyway, I am counting on you guys, that you already have some smart plan in your heads to include this feature while preparing new major JIRA release seriously redesigned one day.
Regards,
Wojtek
P.S. To “Anonymous (angry) Blogger”: I think you haven’t understood too much of what Mike wanted to convey. Anger has made you blind. Do you really think that if they had started “fucking” customers 4.5 years ago (almost at the beginning of the company), so many people would have been using their products and have been happy about it? Switch better to companies like Microsoft, BMC or HP. They will “surely” do whatever you – customer – want from them… “Ignorance is bliss”.
I see two problems there:
1) There are no common understanding what user should expect after submitting an issue to a public issues tracker. When you send e-mail to support, you expect answer in a day, otherwise you will likely decide that company doesn't listen you, and requested feature will not be implemented soon.
But there is no common way to deal with issues in issue tracker. Should company answer each message from customer ? Update state periodically (how often) ? Resolve "won't fix" ASAP or wait and collect feedback for years ?
Early resolve with "won't fix" ASAP seems like a good solution, but this can lead to many new similar issues, while storing them all in one place have major benefits.
This problem is common for many companies which use public issue tracker - be warned. I don't know a good solution for it.
2) "Popular Issues" is NOT "Road Map" for mature products. Actually, #50 in "Popular Issues" list have 47 votes now - this should be enough even for HP or Microsoft to consider such feature requests. Feature requests that fit product architecture or target customers should never reach this high value. Consider "Popular Issues" page as easy way to check what product (JIRA) is not and decide how you can live without all that features. Don't hope that you can force Atlassian implement them - many of them looks simple, but have major side effects and can lead to worse product once implemented.
5 years ago when we were both working on enterprise level issue tracking systems at the same time (I was working on Scarab), I noticed that your database design didn't take this into consideration and in Scarab land we were fully aware of it. Anyway, I *knew* this issue would come back and bite you in the ass. That sucks and I'm really sorry you are having to listen to the flames now.
I happen to be the author of an issue tracker also, also 5 years old. I am in the same boat (ok, a MUCH smaller boat, but the same KIND of boat) as the Jira folks. I completely empathize with the Jira developers and am impressed with how they are handling the FLP issue.
I look at the "Popular Issues" list and by chance, my tracker can do a couple of them, not because I planned for them, but because by chance, I just happened to make a left turn instead of a right turn when making a coding decision 5 years ago. But, there are other features my users are asking for (that Jira CAN do) that I will probably never be able to deliver, because they would require me to pretty much rewrite the app and break backwards compatibility.
Items from the "Popular Issues" list like "Priorities, Resolutions and Statuses per project / issue type", "Sub-issues should be able to contain their own sub-issues", "Assign issues to multiple users or a group", "Make field required only for one state transition"... , these would be like the FLP issue for me and my little tracker. I'm actually about to tackle a little tiny bit of FLP, just a little, and that's pretty daunting for me already. I sure hope I don't break much....
Another dilemma for Jira would be how to add complexity without hurting the first impression the app makes for folks who are doing an evaluation of several trackers. From my readings on the web about Jira, there are some people who have done a round of issue tracker evaluations whose first impression of Jira was, "too complex". I'm not saying Jira IS too complex, just that evaluators have had that reaction. So the evaluators end up choosing a simpler tracker - lost business for Jira. Maybe down the road that simpler tracker ends up being too simple, something they outgrow, but by then there is lock in, it's too late for Jira.
Post a comment
About
I'm the co-founder and CEO of Atlassian.
I live in Sydney and San Francisco. I'm an Aussie. I travel (a lot). I learn. I read. I talk. I create. I bike. I drink. I'm all in.
This is my blog. Welcome!
Atlassian
Atlassian is a customer-driven software company, combining brilliantly simple tools with legendary service.
About Customers News Developer
Daily, over 10,000 organisations from 98 countries use our tools:
- JIRA - issue tracking, project management and workflow.
- Confluence - the enterprise wiki. collaborate and discuss.
- Bamboo - the Zen of continuous integration.
- Clover - code coverage analysis - test with confidence
- Crowd - single sign-on simplified.
- Crucible - efficient peer code review.
- FishEye - source code repository insight.
Oh, and we're always hiring. If you're reading this, there's a good chance you're our kind of person. See open positions.
Photos
|
Search
Mates
Investments
Advising startups is something I've started doing in the last year. It's a fascinating way to use one's brain and experience to solve other people's problems.
I'm loving it.
Besides the few I advise, I've invested in one, HomeThinking.
HomeThinking provides realtor reviews, ratings and metrics (qualitative and quantitive) for home sellers.
I also make a lot of small microfinance loans to entrepreneurs around the world through Kiva. Read more about my on going Kiva Challenge (update).
