16 ms·

When users never use the features they asked for

• endisneigh 5y ago
  This was a nice article, but I’m not sure the title is representative of its contents. I think the first (Keep your users in the loop, always. Do not go build in isolation) or second to last (A user's workflow is everything ) bullet the author uses for their summary is findings to be more enlightening and representative. Internal tools definitely require a close relationship with some set of users to really validate what’s being worked on. It’s just too easy for teams to make unused internal tools. The feedback loop is generally just not there initially. You really have to go and find some users. In this way it’s similar to pre-seed stage startup life.
• valparaiso 5y ago
  Ha. Title is right about Android fanatics and Apple.
• david_allison 5y ago
  Great article, but I disagree with the premise. Code review is too late for most automated analysis (at the level of: "parameter isn't validated" as seen in the screenshot), it should ideally be done as a compiler/lint check in the IDE, and at worst as a git pre-commit hook. In most cases it's not worth sending a code review if there is automated feedback which can and should be addressed before a human sees it. It streamlines the reviews for reviewers, and gives new contributors a much better experience as they have less feedback to address, and more confidence that their code is correct.
  • 3pt14159 5y ago
    Your comment is more true today than it was back then, not that I disagree with you posting it. Back then linters were a twinkle in the hopeful eye of software devs. Now they're battle hardened.
    • buescher 5y ago
      Back then was 2018. Lint dates from the seventies. I doubt it was the first static analysis tool, either.
      • lamontcg 5y ago
        It seems like autofixing linters got popular about 10 years ago? That was when it hit my radar at least, but before that I wasn't really a software dev. Whenever it happened that was a quantum jump in usability.
      • 3pt14159 5y ago
        You're right. I read 2008 in the post and thought the writer was talking about a time shortly after then. By the late 2010s linters were prevalent.
    • david_allison 5y ago
      It's a 2018 paper, but definitely: it feels like something that's come to the forefront in the past 6/7 years and I don't think people are leveraging it enough. It's so nice to be able to write a compiler/lint rule with a quick fix and then see it catch both my own mistakes, and potentially remove a concern/checkbox from the code review template
  • Quarrelsome 5y ago
    There's nothing more frustrating than a stupid machine telling me it knows better when it doesn't. I used to work on a team where the build defaulted to fail if something wasn't used and debugging was a fucking nightmare because the moment you comment out a block of code there's a cascade of warnings into errors that is just never ending (it was typescript so it leaked all the way back to module definition). I had to piss away some time to write a script to turn a bunch of the rules off and then remember to re-enable them later or I'd break the build by breaking someone's OCD.
    • marcosdumay 5y ago
      Well, don't turn warnings into errors. Doubly so on your development environment. That's not a good reason for not running a linter while developing. But, of course, if the decision was out of your hands, people that do that are usually the same that enable all linter rules. Neither decision makes for a good development practice.
    • macando 5y ago
      Had an issue like that. The workaround snippet that fixed it was aptly named stfu.js by the author.
      • Quarrelsome 5y ago
        I went with the commands: > implaying and > srsbsns to toggle it off/on.
  • unholiness 5y ago
    One automated thing I've been really wanting to add to our code review process is copied code detection, where a piece of code is very similar to code somewhere else in the product (though likely not part of the current review). Obviously there's cases where this is code smell, but plenty of times it isn't. It's not something that you would want to block shipping. But if you do want to ship code like this, you should do so with the reviewer(s) fully seeing where it came from, to make sure everyone agrees that's the best way. No one has implemented a bot for us that would add such comment for use but I do think it would be a huge win.
    • 2143 5y ago
      Sonarqube has, among other things, code duplication detection, where it detects very similar, but slightly different blocks of code. It's possible to wire things up so that it runs when you open a merge request and notifies you via email the results. It's not a silver bullet though. It also has a linter plugin for vscode (and possibly other editors) that DID NOT work well, atleast the last time I checked which was before February this year. Just thought you should know, incase you decided to just use the linter. https://www.sonarqube.org/ https://www.sonarqube.org/
    • thrashh 5y ago
      It’s not automated but IntelliJ does this.
• ipaddr 5y ago
  People will buy products because if features they will never use. Not building costs money.
  • 542458 5y ago
    This is particularly true if the “users” aren’t the ones who are signing the cheques. Sometimes shiny stuff that looks good in a product demo or on the trade show floor is what it takes to actually move units.
  • otterley 5y ago
    Case in point: 90% of the pickup trucks sold in the USA.
    • asdff 5y ago
      Or cars in general. So many huge SUVs with three rows of seating being driven by a single person. In other countries people would just use a moped.
• datavirtue 5y ago
  I was hoping for a good old fashioned, negative developer rant.
  • rightbyte 5y ago
    The author is atleast referring to those rants as "angry mails" he got. I think these automated CI systems is a losing battle. It makes the build chain to complex. There is too much corner cases that gives false positives unless you keep it dead simple, like eg. enabling all warnings are errors or something in gcc.
• deleted 5y ago
  [deleted]
• kerblang 5y ago
  One of many things I learned from writing software just for myself is that I'm just about as bad as anybody at figuring out what I really want, even when I'm talking to myself. I've even had one or two cases where I ignored a feature I asked myself for, and much later realized: Hey, I could actually use that. The worst is asking myself, "How many times do I have to ask for this before you quit procrastinating and just get it done???" I'm not sure which of me is the bigger jerk.
  • Arrath 5y ago
    Oh hey its me. I've done some painstaking work to add a feature (hell, even just an excel macro that at the time seemed useful) and realize like 9 months later I've used the feature a whopping 3 times.
    • brokenmachine 5y ago
      Try to enjoy the journey, not just the destination.
  • austincheney 5y ago
    The challenge there is when people start using your personal project. Yes, you remain in control and you remain the primary user. But… now regression and features become a much greater concern because the last thing you want to do is harm other people even if they are only a secondary audience. As the project grows this becomes the most pressing concern regardless of who is the primary user. That begs the question: Why bother growing the application beyond the smallest set of explicit use cases? When you are the primary user AND the only use environment or input samples are written by you life is simple. The moment you must analyze something not written by you, even if this usage is only for you, the problem cases blossom. If your application refuses to solve for those cases then you need to add more features or use a different application. Those two scenarios seem to feed each other which becomes evident by traffic or usage numbers as you pull your hair out keeping up with some hobby application.
  • matheusmoreira 5y ago
    Sometimes it's wise to ignore what you want. So many times I started a project only to end up with 3 libraries and a custom build system. It's like I can't help myself. It got to the point I was too embarrassed to publish these things on GitHub.
• caseyross 5y ago
  When you ask people to imagine a feature, they're going to imagine the absolute perfect version of the feature, for them personally. A feature that requires no effort to set up or use, provides exactly the information or functionality they want, and never gets in the way of anything else. Everyone takes for granted how smooth their own workflow is to them, both because they're already used to it, and because they sunk effort into it to make it smooth (via learning or planning), which has probably been forgotten. So, people just take for granted that new features will maintain that acquired smoothness --- unfortunately, they usually don't. As the author found out, most of the work in building features is often not in the "raw functionality" of the feature, but rather in making something that performs its functions while also not costing the user significant extra mental or physical effort to use.
• adamm255 5y ago
  Nice post. I liked this take away. "Users say things for a reason, but there may be more to it than face value." Theres often more to what a human says than face value. The key is to always be asking questions, always ask why, multiple times. Ask questions until you feel like you're on the edge of pissing someone off. Often, a good bit of time up front can get to a few outcomes which save you a massive headache. 1) You understand the feature so well, you're ready to go and know it will be used. 2) The REAL ask was something totally different, and now you know what you need to do (nor not in some cases, sometimes its training, using the product properly/as intended etc). You're also going to be giving the requester the space to fully explain themselves, and sometimes they can talk themselves round as well. At the end of the day everyones a winner when we ask more questions and listen.
  • new_guy 5y ago
    The 5 whys https://en.wikipedia.org/wiki/Five_whys https://en.wikipedia.org/wiki/Five_whys
• strict9 5y ago
  A metaphor for this situation (building exactly what customers ask for) could be the car Homer Simpson designed ("The Homer"). https://simpsons.fandom.com/wiki/The_Homer https://simpsons.fandom.com/wiki/The_Homer Not that all users are equal to Homer, but what they think they want and what they actually need are very different. It's better to get more detail on the problem, then present a series of possible solutions to evaluate and iterate on.
  • smusamashah 5y ago
    Not just that. If the feature is given in an usable or other poor form. They won't use it even when they have it right there. May be its not very obvious, or complicated, or too time consuming. Design makes all the difference. If you give them something they never needed or asked for, but it's so obvious and simple to use, they will use the hell out if it.
  • 72f988bf 5y ago
    Went down the rabbit hole from your link: > > It is a parody/exaggeration of the Edsel, a similarly disastrous automobile designed by Ford Motor Company. Points to https://en.m.wikipedia.org/wiki/Edsel https://en.m.wikipedia.org/wiki/Edsel: It has a "Design controversies" section that's very relevant to today: > Complaints also surfaced about the taillights on 1958-model Edsel station wagons. The lenses were boomerang-shaped and placed in a reverse fashion. At a distance, they appeared as arrows pointed in the opposite direction of the turn being made. When the left turn signal flashed, its arrow shape pointed right, and vice versa https://en.m.wikipedia.org/wiki/Edsel#/media/File%3A1958_Edsel_Villager.jpg https://en.m.wikipedia.org/wiki/Edsel#/media/File%3A1958_Eds... Why is it relevant? Related thread from 3 days ago about blinkers with the exact same design flaws , but in 2021: https://news.ycombinator.com/item?id=28661282 https://news.ycombinator.com/item?id=28661282
• KirillPanov 5y ago
  ... and this is how we got WebUSB.
  • deleted 5y ago
    [deleted]
• deleted 5y ago
  [deleted]
• deleted 5y ago
  [deleted]
• commandlinefan 5y ago
  I once spent a week working on a fairly complex feature for a product that the users were demanding almost daily updates on. I delivered it and, by coincidence, happened to be where the users were a couple of weeks later and I stopped by to say hello and saw that the user who had been asking for the feature every day was still using the product the "old way". I asked why and he didn't seem to follow what I meant, so I reached over and showed him the feature that he had been demanding I add and he said, "oh, wow, that's awesome, that's going to be such a huge timesaver for us!"
  • DrammBA 5y ago
    How subtle was the update message letting the users know about the new feature?
    • garmaine 5y ago
      Yeah sounds like the lesson here is that nobody reads the update messages.
      • Semiapies 5y ago
        Couldn't have anything to do with how app update screens share the exact ergonomics that subscribe-to-the-newsletter nags and other ad popups have.
      • csydas 5y ago
        If quantum scientists thought the slit experiment was exciting, they should study IT user preferences and be amazed how depending on the mode of communication/observation, customers will both scrutinize every letter you write while simultaneously not reading it at all, will know every wrong pixel of your UI but not know where the button for "Thing" (labeled "Thing") is, and how anything you make is somehow the best worst average thing they've ever seen. If you're ever user facing it's a harsh but quick lesson that you can't really count on any users to follow any real pattern. Different persons latch onto different things, with adamant proponents and opponents of everything with a huge swatch of grey shades in-between. At a certain point you just need to decide when the "grey" is no longer grey for you on a particular subject and start to optimize for the part that cares while checking why the grey part isn't as interested. A lot of conversations with clients I have are with those in the grey territory, where they don't quite know what they want but they know they want it. Often times, they're more looking for a reference architecture and something to compare their current processes/workflows to, and this usually is pretty simple to work with. Those that are proponents of a feature N are typically vocal and picky, but the feedback tends to be pretty good and the guidance is clear on how they envision it, since there's a clear workflow on their side a lot of times that they want to optimize. Opponents of feature N typically bring out the edge cases and demand a solution, and are equally, if not more vocal than the proponents. It's really a tricky thing, and it's never really clear which is going to be "best" for users/the dev team.
• huang47 5y ago
  thanks for this great write up and I wish I could read this 10 years ago :).
• yupper32 5y ago
  A fine post and I'm sure a fine tool, but why is an internal linter tool the subject of a proper academic paper? I can't imagine writing an academic paper for any of the projects of similar complexity and general interest that I've worked on.
  • beecafe 5y ago
    You should consider it then! Having concrete data about anything in a peer reviewed form is always valuable.
    • yupper32 5y ago
      It seems like a waste of time, when a just blog post could be 95% as helpful and be way faster and easier to publish. You don't need peer review for everything.
• everdrive 5y ago
  Sometimes I wonder if software is becoming worse because logging is coming better. We have so much data about problems that users are having, feedback they're providing, etc. Perhaps following the mass of people is the root cause of software's constant and worse UI changes.
  • quickthrower2 5y ago
    Jira takes the biscuit with their text editor. Always changing and hard to make sense of. Recently ctrl-enter and enter actions were swapped!
    • Minor49er 5y ago
      My favorite thing about their text editor is that it will delete all of your changes with no option for recovery if you accidentally hit the escape key. I also like how this has been an open issue for many years on Jira, but they refuse to change it for some reason (or at least that's the state of it the last I checked about a year ago. Thankfully, I don't have to use any Atlassian products anymore.)
      • allannienhuis 5y ago
        I HATE that! too many times my vim muscle memory has cancelled out of a long comment or issue description :(
• macando 5y ago
  > Turns out there were a few hiccups: everyone involved in that project we wanted to use had left the company, we had no idea how to build the source code, it had something like 500,000 lines of code, and the one person we found that knew anything about the project was 13 hours ahead and stopped replying to our emails. When you don't talk to users this is what you end up with.
• oceanghost 5y ago
  Before the launch of the XBOX 360, the company I worked for was one of their suppliers, and without going into enough detail to make me identifiable, the management of our two companies had arrived at sort of a stalemate: We didn't want to tell them exactly how our algorithms worked, and they didn't want to tell us exactly what they were doing with them-- think of it like a data compressor where, we don't want them to know the exact compression algo, and they don't want us to have their data. So, somehow, It is arrived at that a website will be created that encodes MS's proprietary data, but doesn't store it, but also our algorithm is implemented server side, so there's no leakage of proprietary stuff. A month later, the app is done and tested and I'm decoding data from the website on real hardware. I move on to the next project. Three years later, the Xbox 360 is out, I decide I'm tired of filling out reimbursement forms for Heroku and its got to be a security risk with no updates in 3 years... so I take a look at the apps stats to see if its feasible to shut it down--exactly zero users. Nobody ever attempted to use it, not even once. Ironically and unknown to me, the source code had been lost in a freak accident and when I deleted the Heroku account that was the only copy of the source left. Even worse, a year later someone claimed to have a use for the app and where was it please? And I had to explain we no longer had the source. I remember a very long e-mail about how irresponsible we were.
  • arthurcolle 5y ago
    Cool story thanks for sharing - so how did they get around the issue for three years without the app?
    • oceanghost 5y ago
      Thank you! If they were that serious about security-- the chips we made also implemented this same compression algorithm. It would have been trivial to hook one up to an arduino and feed it the data you wanted to encode. I assume someone realized this, or they never really had a need to encode their own data (we provided a extensive library of encoded data). I strenuously disagreed with the business justification for keeping all this stuff secret. But it was my job to respect those decisions. It was a lot of fun writing the (rails) app itself.
• karaterobot 5y ago
  Slightly frustrated to read this, because this is user research 101! It's really impressive when someone independently discovers practices from an outside discipline, just by observation and inference. However, somebody could have saved this poor guy a lot of frustration by not forcing him to develop a product design methodology from first principles.
  • willhinsa 5y ago
    Is there a book(s) you could recommend for product design methodology?
    • karaterobot 5y ago
      For this specific case (product discovery interviews) take a look at Interviewing Users by Steve Portigal, and Validating Product Ideas by Tomer Sharon.
    • thanksforfish 5y ago
      I found "Don't Make Me Think" by Steve Krug to be a helpful guide. As an engineer who was shy to approach product design, I felt the language really helped demystify things.
  • dclowd9901 5y ago
    They were an intern, but I think it leads to a bigger point I was thinking about as I was reading this: In every org I’ve been in, we’ve had interns do these kinds of things: build big intrusive things that suck and no one uses. The problem obviously isn’t the interns. It’s the projects we give them, which are meant to be basically “throw-awayable”, and the complete lack of actual guidance and oversight. Why are tech companies so bad at actually mentoring interns? They _should_ have had someone teaching them about user experience 101, and they completely let them flounder. How are we supposed to continue to grow and evolve as an industry if we make make every neue klasse start from scratch?
• protomyth 5y ago
  The funner one is unique to enterprise developers. Begged to implement a feature to the enterprise software, the development team puts in a hell of a lot of hours to get this time sensitive feature into the production. Then, out of nowhere, a manager of some import informs everyone that they cannot use that feature as its "against best practices" or some other language to that effect. Bonus points if said manager was on the email chain about the feature and its progress.
  • b0afc375b5 5y ago
    What do you do at this point? People complain about meetings saying that "this could have been an email" (including me). But I believe some people just don't read email/chat/jira comments. Maybe they're busy or just don't care at all, who knows. How else would you get your point across?
    • makeitdouble 5y ago
      I think people don't really follow meetings either. We had a ton of going back to the transcripts to prove topics have been discussed. There is no magic bullet, if someone has the power to make decisions, you are always at the risk of having them change course at any point in time. The only think you can do is deeply convince them it's in their interest you succeed.
• listenallyall 5y ago
  This is relevant perhaps 10% of the time. The other 90%, the devs have absolutely no idea how to actually perform the task the user of the software is trying to do, don't talk to customers, don't dogfood it, often don't even understand the industry, and the result is a horrible UI which forces people to severely adjust their existing processes to fit the software. Then if course the devs complain about "the stupid users." To this day 99% of address forms expect me to find my state from a drop down list of 50 entries plus DC, Puerto Rico, Guam, etc. instead of simply typing in the two letter abbreviation.
  • BeFlatXIII 5y ago
    Not to mention international address forms which expect you to scroll all the way to U for Brits and Americans. I understand the the alphabetical listing is the most internally-consistent way to display to the users, but either putting duplicate entries for the most popular countries at the top of the list or providing a text field that suggests the normalized country as you type ought to be the go-to, not a purely alphabetic dropdown menu.
• xyzelement 5y ago
  I moved from engineering to product management precisely because I realized that the problem of "what should be built" is often harder than building the thing. Asking users what features they want is pretty much not fair - because most people don't have the skills to think through and answer that question, nor is it their job to do it. It's like asking a novel reader what they'd like to see in the next chapter. It's a cop-out with guaranteed suboptimal outcome. Obviously product management is half art half science but in a nutshell, much better than asking an individual what features they want would be asking them - especially on a senior level - what problems they have and what keeps them up at night. Getting an understanding of that and then thinking about how those problems/risks can be addressed by your system is a much better starting point. The reason I say that it's important to partner with your users on the senior level is the difference in perspective on the class of problems they want to tackle. For example I used to work on a trading platform. If I went to my heaviest users and asked them what their problems were, they would probably say "I do 1000 trades a day, and I have to tweak each one manually - can you make that process faster" and maybe even have an idea of what that could look like. So let's say I did that and shaved a second off each trade handling so my user is happy cuz I saved them 16 minutes a day. Sounds like a job well done. But if instead (or in addition) I talked to their boss, I might hear a very different story. Eg: "we do 1000 trades here every day, but 900 of them are straight forward. I wish I could automate those so trader can focus on the 100 complicated ones. But instead, he's so busy doing the 1000 trades that a lot of them get fucked up especially the complex ones." That's a major change of perspective, from optimizing an existing workflow to optimizing the entire operation. The implementation is quite different - one is a UI optimization and the other is establishing some sort of automation capability that can be extended to all my clients over time. One may be doable with the team you have, one may require standing up a new group, etc. At the end, the end user is happy (they get to do 10% of their previous load but this is the high value 10% they really want to focus on.) The key point is that neither the user nor their boss could tell me exactly what to build, but the high level perspective allowed me to understand their problem in a deep way and figure out a scalable solution for them and other clients. Anyway that's just an example but yeah, your users can't tell you what to build and yeah you need a good product manager - or someone who can play that role well.
  • 5y ago
• serioussecurity 5y ago
  Microsoft didn't run automatic code analysis tools as part of their code review process until 2017? What on earth was wrong?
  • easton 5y ago
    They wrote a bunch of them (StyleCop among others) for C#. And Intellisense which relies on being able to analyze code all kinds of ways. I find it hard to believe they didn't.
  • mr_toad 5y ago
    > What on earth was wrong? The automatic code analysis tools. Sure they existed, but they need to fit into a workflow and get approval for use (which takes about ten years in enterprise these days).
• c_o_n_v_e_x 5y ago
  "When users never user the features they asked for..." At least they are users asking for a feature. I've lost count the number of times where a sales guy swears up and down that he'll close the deal if we put features X, Y, and Z. The C-Suite gets hot and bothered about closing and I get overruled. Stories for X, Y, and Z get written, backlogs reprioritized, features developed. Ta da! Then what happens? "Customer" goes dark and we never hear from them again. ::laughcry::
• tabtab 5y ago
  I find it's usually release with the minimum necessary features first. Once they digest those, then add on the next set based on feedback. The more incremental the better. But do keep likely future features in mind, such as leaving space in the tool-bar etc. Certain things are hard to retrofit after the fact.
• deleted 5y ago
  [deleted]
• kureikain 5y ago
  So I want to share a story about user asking for a feature then not using it. I run an email forwarding services(https://hanami.run https://hanami.run) basically you add your domains in and add some records. We had this one heavy users who has like hundreds of domains. So our UI isn't design for that. Who has hundreds of domains? So they approach and asked us for a way to organize those domains into a hierarchy structure. All good. They are paid our highest tier ($30 per month) so we prioritize the requests and work on it. 2 days later that same user downgrade to the lowest plan and delete all of their hundred of domains... That complicated features remain unused to nowadays...
  • smoldesu 5y ago
    If I'm being honest, that sounds like a net win for you and your company. Even if they aren't still around, now you've got a better and more attractive interface!
    • xyzelement 5y ago
      Yes but the question is - what do they NOT have because of this. Sounds like they bumped something more valuable to get this done.
      • darknavi 5y ago
        Any how much does it cost to maintain a not-used, complicated feature going forward.
        • grujicd 5y ago
          This. Now every new feature in that area of code is more complicated than it could be, for no benefit.
  • alpha5 5y ago
    It's a pretty cool tool. You just got a new customer :)
• jimmyvalmer 5y ago
  Requesting features is like packing for a trip with a bottomless suitcase. You might wear those shoes, read that book, or use that racquet, or you might not -- costs you nothing to pack it, though.
• chefandy 5y ago
  As the author eventually understands— users almost always want the features they ask for, but they may not the interpretation of them you've created. I recently started working in design after being a developer for more than a decade. Back then, planning how things should work for users felt frivolous compared to coding. Beyond that, getting working code in the editor just felt so good that I never wanted to put it off. These are the excuses I'd make to avoid really thinking about the users: - I can clean up the interface later - I'll figure out what features I can support when I figure out how it's going to work - I've got a good intuitive sense of what would be most useful and how people want things to work Unless the tech requirements are extreme, knowing what features are helpful and how users will use them should inform development— not the other way around. Also, overestimating your understanding of how people want something to work almost always leads to suboptimal results. Unfortunately, this mindset led to clunky, miserable interfaces that many people rejected. Worse, core users would learn to love it because they had no choice, and they'd develop bad UI Stockholm syndrome. Nothing carves a lousy user experience into stone for all future users like reliable core users demanding nothing changes. Obviously, solo intern projects are an edge case, but this case study perfectly illustrates the necessity of user-focused design is in software projects. All the better if you can find someone who specializes in it. UX expertise brings: - deep experience reasoning about the way people use things - knowledge of many workflows, working styles, and personalities - understanding of how much deviation users will tolerate - familiarity with user research techniques and their shortcomings - ability to distinguish between research signal and noise - knowing where to dig deeper or seek more data - understanding what needs to be prototyped vs. mocked up vs. textually described for tests, and ideally the ability to do all three That perspective built into this project from the beginning would have completely changed its trajectory. Users would be less irritated, and the developer could have used wasted rewrite time making a more valuable end product.
• democracy 5y ago
  It's a great story - thanks for sharing. People don't want to offend other people, so normally you not gonna get negative feedback when talking to someone face-to-face. Also for the code review tool - it's a sort of "consultant issue". I work on the floor and probably overworked (and maybe stressed). Then a random person shows up with an "improvement" pretending to be of some use to me. Thanks, but you should ask me first what needs to be improved in my day-to-day job. That only causes negativity. Not sure if this was the case, but close enough.
• zw123456 5y ago
  “Some people say, "Give the customers what they want." But that's not my approach. Our job is to figure out what they're going to want before they do. I think Henry Ford once said, "If I'd asked customers what they wanted, they would have told me, 'A faster horse!'" People don't know what they want until you show it to them. That's why I never rely on market research. Our task is to read things that are not yet on the page.”
  • makeitdouble 5y ago
    This flies pretty opposite to what the lessons the author got from their experience ("Keep your users in the loop, always. Do not go build in isolation.", "If you make assumptions about your users, they will find a way to surprise you.") I kind of feel your view is a variation on "if you built it they will come", which is true in some cases, and will wield spectacular failures in ton of other cases.
    • zw123456 5y ago
      It's a Steve Jobs Quote. Sorry should have put that there but it's so well known I guess I didn't think to. But I think it is a little of both. To much of the Jobs approach can lead you down errant paths, but if you never anticipate what the customer wants you could miss great opportunities.
      • makeitdouble 5y ago
        I think what Steve Jobs calls "market research" is mostly customer panels, polls and actual straightforward "what do you want" questions to users. Apple did extensive research when designing their products, just not the naive/lazy kind that would be offered if they went to an established marketing firm. This bias was also what bit them when they designed the trashcan MacPro, or the following coming to term with needing a Mac Pro at all.
• pugworthy 5y ago
  You know what's worse? When you have no metrics and have NO IDEA whether users are actually using the features you ask for. I realized this a while back due to the fact we had a feature on customer request, which was in release for some time. It had a bug in it, and nobody ever told us about it - which told us nobody ever used it. And the only reason I know nobody used it is that we collect no metrics. And yea I'm working on that with the company...
• otterley 5y ago
  "Don't underestimate engineering challenges that you only have an external view of." I wish more people would heed this lesson, especially in HN comments.
• roland35 5y ago
  I once stayed at work for 36 hours straight to finish assembling a batch of circuit boards for a customer's prototype. I dropped them off at FedEx for next day AM shipping right before they closed on a Saturday and felt pretty good to just barely make the deadline!! Well Monday morning, the customer assembles the first prototype and it lights on fire. Turns out there were lots of other problems and all my work was for nothing. I learned a lot from the experience!
  • rendall 5y ago
    > all my work was for nothing No way. Not for nothing! The customer did not have the added problem of late circuit boards. Even if they could not build their prototype, you did good.
    • Orionos 5y ago
      Also, who doesn't like to gather around a nice flaming circuit board on monday morning to warm everybody up and enjoy a coffee
• deleted 5y ago
  [deleted]
• sharmin123 5y ago
  Can iPhones Be Hacked | 5 Ways to Know Your iPhone Is Hacked: https://www.hackerslist.co/can-iphones-be-hacked-5-ways-to-know-your-iphone-is-hacked/ https://www.hackerslist.co/can-iphones-be-hacked-5-ways-to-k...
• cratermoon 5y ago
  Warning: vague, hand-wavy half-memory incoming. One place I worked at had a tool, I forget the name, that could record and report on which features and parts of the site where got used and how much. At one point we were discussing a particular bug we found and how much effort it would take to fix it. I asked my co-worker who happened to have the usage reports at her fingertips, because that was her thing, how much the feature was used. Just wanted to prioritize it. Zero. Users had never touched the screen the entire time since it was rolled out. I expressed my sympathy for the developers who worked on it because they were told it must be done, but it was an easy call to throw the bug into the WONTFIX pile.
• topkai22 5y ago
  Total aside, but the chocolate milk and coffee concoction he describes in one of the pictures was also my drink of choice. I dubbed it the Microsoft Mocha, although I don’t think the name caught on.
• topkai22 5y ago
  Total aside, but the chocolate milk and coffee concoction he describes in one of the pictures was also my drink of choice. I dubbed it the Microsoft Mocha, although I don’t think the name caught on. It definitely fueled the pursuit of multiple good (and bad) ideas during my time in Redmond.
• glangdale 5y ago
  We found (in the world of building Hyperscan, a high-performance regular expression matching library) that asking users what features they wanted was a disaster. You have to ask them what they want to achieve. Their suggestions as to how to do it were almost always terrible: partly, they don't have the domain knowledge to know what's going to be simple and practical vs complex and nasty. Also, they usually have a comparatively clear picture of what they want to achieve, but their notions of how best to break that into "your problem (library)" vs "our problem (app)" are often very naive - you wind up owning way too much of the problem (usually), or occasionally going in the other direction and not really getting enough context information into your library.
• tchock23 5y ago
  One pitfall I’ve seen user researchers fall into is they are obsessed with recruiting a fresh sample of users for their ongoing rounds of user interviews. This recruitment requirement skips much of the understanding of user needs, priorities, workflows, etc that came from previous rounds of exploration and testing. The real value comes when you gather a small but roughly representative sample of users and collaborate closely with them on the development of feature(s). For example, I recently built a ‘User Advisory Board’ to guide the development of internal tools at a large organization (using software I developed for that purpose). This subset of users was engaged throughout the development process - collaborating with designers and engineers throughout - resulting in a finished product that was closely aligned with user needs. I don’t have data to back this up, but I got the sense users were more satisfied with the end result because they felt they had a hand in ‘co-creating’ it (aka ‘the IKEA effect’). OP claims they did this early on, but my comment is pointing to a larger issue I’ve witnessed that may help those reading this to avoid the issue of users not adopting features they asked for…
• justicezyx 5y ago
  I'll have to jump out and point out that this is exactly the type of study that I feel the academia nowadays more or less are forced to perform, but at the same time have questionable setup and limited impact. Overall the study is performed a very limited time frame, with a last portion of the data analysis performed through emailing back and forth. The research scope is limited to 300+ organization, which in fact has 30000+ engineer in total. And the tool was developed without much of normal industry standard understanding, aka, introduce a code analysis tool requiring users explicitly invoking it (I think anyone who is at a typical senior level in large Corp knows that without management pushing, such change is never going to work). The mentors of the author might be full time researcher? I am not really nitpicking or condescending. I am dismayed by the waste of time and effort on both sides. I'll read the paper later. But I suspect it would be basically some well known facts in the dunstry...
• danjac 5y ago
  I remember a conversation with an inexperienced PM, who was still in the mode "we need to add X because a customer asked for it". What I've learned - although I've never had a PM role - is not to blindly just give customers what they ask for, but to figure out what they really need. Their feature requests are often a proxy for something else they aren't able to articulate. Another thing to be careful about is adding that one thing a customer asks for but nobody else does. You end up wasting cycles and bloating the product with these one-off asks. Sometimes you have to stand your ground and say "no", because the ROI just isn't there. Startups in particular are vulnerable to this because they haven't got a large enough customer base and capital yet to comfortably say "no", and end up with features jammed into the codebase that are still there, years later, when the original customer that asked for them are long gone. There are exceptions of course - perhaps the feature is for some legal requirement e.g. "we need to show this specific set of Terms & Conditions before the user clicks Yes" they must have and can't live without.
  • amitport 5y ago
    If it's in the enterprise sales phase then sales will just say "yes, no problem". Ideally they will talk with engineering, but...
    • danjac 5y ago
      To be totally fair to sales people, it's very, very hard to say "no" when an enterprise customer is dangling a contract in front of your nose that means your company keeps the lights on for another year. But enterprise is really something you should look at if you really understand the niche, have lots of contacts, and plenty of patience and runway.
  • skeoh 5y ago
    Somewhat related: https://en.wikipedia.org/wiki/XY_problem https://en.wikipedia.org/wiki/XY_problem
    • jwally 5y ago
      This isn't somewhat related - it's the root cause :-)
• pjerem 5y ago
  I once had to develop a full application with really hard problem solving in a really complex domain that I had hard time to understand. This was for a big national phone operator. We delivered it under a lot of pressure from the sales team (I was in a shitty company, with few employees) and the contract was in multiple millions euros. That was literally one of our 2 or 3 customer. We delivered. One day we eventually get paid (our customer was well known in the industry to pay only when they are forced to - yeah, shitty customer too). The project is finished, customer is happy with what we demoed and delivered. Then maybe a year later, we decided to add a feature to this product to be able to sell it to another client. I got pull and build this damn thing. Nothing worked. Like, nothing. The login form was broken. Then I remember. A full year and not a single support ticket. The company owner « joking » about how our sales team used alcohol, parties and embarrassing photos to make their customer buy our software. The insane amount of pressure we had to deliver this technically hard project. I left this company the day this popped in my head.
  • rm445 5y ago
    That's a crazy story. My guess would have been, not that the product never worked, but that the delivered version was hacked together in the last 24 hours before delivery and never made it into source control. You know the technical details - do you think something like that could have happened, or really no one tried to use the product even once?
    • pjerem 5y ago
      No, I don’t think it was changed. I just think that the people who bought the tool weren’t the engineers who needed it and that for some reason the engineers never ended using it, maybe because they didn’t even knew about the existence of the tool or because they felt it was useless to them. I don’t even remember them to be involved in the project, but once again, shitty company, I had no direct contacts with the end users. Everything was proxied with their buyings dept, our sales dept, and our product « managers » (who really liked their job of not being anything more than well paid proxies between sales and programmers). With this setup, I’m pretty sure our product, as complex as it was, was probably useless to them. But meh, I left this company and I now work at a nicer company where I’m truly motivated knowing our end users enjoy using our products.
• alin23 5y ago
  This happened to me so many times. Like when multiple users asked me to add monitor brightness dimming when the sky is covered with clouds in the Location Mode of my app for controlling monitors: Lunar (https://lunar.fyi https://lunar.fyi) Turns out cloud cover reported by weather APIs isn't a good predictor of the ambient light. The feature was so useless (and expensive because weather APIs are not cheap) that it never made it into a release. What the users really wanted was an external ambient light sensor that they could place where they're working and have the app adjust the monitor based on that: https://lunar.fyi/sensor https://lunar.fyi/sensor Even with the high entry barrier (buy sensor parts, assemble, flash firmware) it was still more accurate and used by more people than the location based approach.
  • tpxl 5y ago
    > expensive because weather APIs are not cheap Just FYI, you can get free hourly (or 30/15 minute, I forget) cloud coverage data from the likes of EUMETSAT (and equivalent US/asian agencies).
    • alin23 5y ago
      Thanks for the info! I'll keep that in mind for future projects. Since then I also found Open Meteo (https://open-meteo.com/en/docs https://open-meteo.com/en/docs) to be a nice alternative for smaller projects.
• jmnicolas 5y ago
  It's even worse where I work: I'm coding whole apps that are never used. My boss has a continuous stream of ideas that are always urgent and important but end up abandoned once he has toyed with them a few times. The worse one is this app where employees are religiously entering data into it (if the server is down even 30s, I receive logs from them not being able to input data) but nobody uses the data (I check regularly). Before I cleaned it up, my project folder contained about 250 Visual Studio solutions. Only 20 apps are regularly used. I have come to "sense" which projects I should put serious effort and which one I can just do the minimum.
• pbreit 5y ago
  Users are terribly unreliable when it comes to suggesting feature adds.
• brnt 5y ago
  Never? Exaggeration much? Also, features don't have to be used (much) in order to be useful. I don't do Google Take-out on a daily basis, but still that feature existing is a signal I appreciate.
• nfrankel 5y ago
  I was a consultant and I used the rule of 3 whys. When a customer asks for a feature, get back to the root concern by asking "why"?
  • ptman 5y ago
    https://www.joelonsoftware.com/2008/01/22/five-whys/ https://www.joelonsoftware.com/2008/01/22/five-whys/
• menzoic 5y ago
  Building the feature right is hard. They might want it, but not the way you built it.
• pjmlp 5y ago
  Since everyone is sharing their stories. Back in our 2000's startup, our AOLServer like application server, had something similar to what Rails Active Record brought to the world, just in Tcl. Basically each RDMS driver had their own lowlevel Tcl bindings, and then the infrastructure code would wrap them up in the upper layers. So sales got a very important customer, there was a caveat though, they were using Sybase SQL Server, which we didn't had any driver support. Given that we had to deliver no matter what, a war room project was quick started to add support for Sybase SQL Server, across all layers of the product, drivers, model generation, SQL translation, the whole package. In the meantime, the customer got talked into using Oracle as we were getting the finish touches for delivery. When they finally got the new version, with Sybase SQL Server, requested by them as hard requirement, they decided to just keep using Oracle instead.
  • mach1ne 5y ago
    Did you at least have use for the Sybase support at some point?
    • pjmlp 5y ago
      Not really. I guess the only benefit was that on later releases, we could share the infrastructure with Microsoft SQL Server. For those that don't know, Microsoft SQL Server grew out of a partnership with Sybase, and the early versions were quite alike, just Microsoft version had better GUI tooling.
• zxcvbn4038 5y ago
  Then you have Slack which forces everyone to use features nobody ever asked for. AWS which ignores what people ask for until it happens to align with something AWS wants. Microsoft which only implements what their double platinum partners program people asks for and forces everyone else to use that. Oracle which gives people what they want and sues everyone who gets it from someplace else. Google gives you what their algorithms determine you want. Like community support of all their products. You wanted that. They can prove that mathematically.
• mojuba 5y ago
  In short: don't let your users become your product managers. The real PM's exist for a reason.
• dagw 5y ago
  I once spent 6+ month working on a feature that was to be one of the flagship features of our next major release. We'd talked to several major customers about it and gotten lots of positive feedback. Once released, virtually no one used it and no one cared. On the flip side the by far most impactful feature I've ever added to any software in any point in my career came a couple of years later when working at the same company. It was inspired by an offhand comment by someone in a meeting, and it wasn't anything anyone had ever asked for or even really solving a problem customers claimed to be having. I'd 'coded' the feature on a piece of paper by the end of the meeting and implemented it 2 days later, mostly just to see if it would work. I quietly added it in a minor point release with only a 1 line mention in the update doc. That feature went on to become an everyday part of most of our customers workflow, and transform how they used and interacted with our app. Nobody, least of all me, had any idea how useful our customers would find that feature.
  • stnmtn 5y ago
    I find this fascinating. Could you lay out what that feature did, generally?
    • dagw 5y ago
      It was an app for viewing, exploring and analyzing certain large, complex heterogeneous datasets. Both features where, at their core, essentially an additional novel way to view and explore that data. It's just that the second one really clicked with a lot of people in ways no one predicted. If was to draw some conclusions, it would probably be that the successful feature made a common task a little bit easier for a lot of people in basically all use cases, while the 'failed' feature attempted to add an entirely new type of analysis/exploration to the application that it turned out people didn't need as much as they thought they might.
• Borrible 5y ago
  I work mainly in BI. Data mangling, Dashboards for the simple minded, pretty reports, such things. I somewhat like the more informal atmosphere of SMBs and normaly I'm regarded as some strange kind of Wizard (of Oz of course). Thank god, seldom I have to face a Dorothy. More often cowardly lions and Tin Mans. So, I more or less do what I want. And what's right of course. That means, I monitor the user behaviour meticulously and remove unused features without feedback from time to time. In the past I always asked before, but that meant to impose some decision on them and they don't like that. It awakens their bureaucratic white collar sub instinct. Some of them can't even remember such features were requested by them or even used one or two years ago. The timespan I use as a rule of thumb after I make a feature disappear. They can be outright indignant I imply they don't know anymore, what they did or knew. I even had the chutzpah to suggest the feature again some time later. Never had a problem.
• DoubleGlazing 5y ago
  I was part of a team that the developed a workflow management system for managing telecom's infrastructure. We were really quite proud of it, it pushed our boundaries during development and we learned a lot of new skills. It was implemented exactly as per the clients spec. It was also quite expensive, my employer billed them €300,000 for the work. They accepted it.... and then didn't use it. There was some use in the first few weeks, but then it petered off - despite this they kept paying us to manage the hosting and suuport of the system. After a few months our manager approached them to ask if everything was Okay. Their response was to say the thought it was an amazing system, but now they realised it was way over-specced and using it was more of a burden than they expected it to be. I suppose it was the software development equivalent of ordering the biggest thing on the menu and then regretting it.
  • akudha 5y ago
    We buy books that we don’t read, gym membership that we never use, clothes we never wear… I guess corporations are no different?
    • mettamage 5y ago
      I'd like a well researched blog post on this, outlining when/where this does or doesn't happen. So if a savvy writer is reading my comment, here is my hope in that it'll be picked up! :)
• johnmato 5y ago
  This is usually happening with smartphones; there are a lot of consumers who tend to buy the latest model because of its features, but as time passes, they tend to ignore the feature.
• ourmandave 5y ago
  Summary at the end. Writing this story makes all of the problems and solutions sound so obvious. Hindsight... Let's review a few of the lessons I learned: Keep your users in the loop, always. Do not go build in isolation. Don't underestimate engineering challenges that you only have an external view of. Voice your concerns to your team regularly and often. They might be to solve them far more quickly than you or they might be able to identify what will turn into a major roadblock. Be ready to pivot. Users say things for a reason, but there may be more to it than face value. If you make assumptions about your users, they will find a way to surprise you. Features will go unused if they aren't easy to use, no matter how great they are. A user's workflow is everything. (I keep relearning this lesson...) Users are far more clever than you think.
• failrate 5y ago
  At no point in the first half of the story (ran out of time to read the whole thing) did I see the author using their own code review tool!
• rawsta 5y ago
  I remember the time we urgently had to develop an application for our Client. We had to work overtime to make the Deadline. After 3 years we had to Upgrade the Server an found a Bug that crashed the whole application. But apparently in 3 years nobody even looked at it.
• gveiga 5y ago
  I wrote an article some time ago on this exact mistake that product teams do. I called it the baby bias: https://www.linkedin.com/pulse/baby-bias-how-start-product-discovery-gon%C3%A7alo-veiga https://www.linkedin.com/pulse/baby-bias-how-start-product-d...