Summarizer

> The load time improvements had destroyed their company culture. Instead of everyone coming into the office, turning on their computers, and spending the next 10min chatting and drinking coffee One of my early tasks as a junior engineer involved some automation work in a warehouse. It got assigned to me, the junior, because it involved a lot of time working in the warehouse instead of at a comfortable desk. I assumed I’d be welcomed and appreciated for helping make their work more efficient, but the reality was not that simple. The more efficient I made the technical part of the job, the more time they had to spend doing the manual labor part of the job to keep up. So the more I reduced cycle times, the less time they had to sit around and chat. Mind you, the original process was extremely slow and non-parallel so they had a lot of time to wait. The job was still very easy. I spent weeks doing it myself to test and optimize and to this day it’s the easiest manual labor job I’ve ever worked. Yet I as the anti-hero for ruining the good thing they had going.

> This makes it critically important that you, the software engineer, understand the purpose and real world usage of your software. Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems. You actually described the job that Product Managers _should_ be doing: "understand the purpose and real world usage of your software".

Everyone in the team should have that. Obviously at different levels of focus and completeness, but the Product Manager is supposed to be communicating in both directions and they rarely do, they just take the feature list and tick them off. Telling the customer that they can't have something or it needs to be different and having their trust that you aren't doing it just to cut corners is what good Product Managers do.

As a developer of new things, if you allow someone else to capture this value from you, you become fungible; additionally, for your group, having technology designed to solve problems without grounded but expansive ideas of how much is possible, limits your team's ability to the mundane rather than the customer delighting. Some product folks have internalized the possibilities but some haven't.

Ideally its a mix, a good PM should understand the customer/market more than the developer has time to do, and then they can have conversations with devs about how to most effectively fill needs. In reality, these PMs seem more like unicorns rather than expected table stakes, but hey.

Lehman talked about the developer-software-user triad. Each of the three have a different understanding of the problem to be solved. Developers misunderstand what the users want, and then aren't able to accurately implement their own misunderstanding either. Users, in turn, don't understand what the software is capable of, nor what developers can do. > Good intentions, hopes of correctness, wishful thinking, even managerial edict cannot change the semantics of the code as written or its effect when executed. Nor can they after the fact affect the relationship between the desires, needs, and requirements of users and the program […] implementation; nor between any of these and operational circumstances – the real world. https://entropicthoughts.com/laws-of-software-evolution

Yes nice but also very naive. Most developers do not have that level of ownership, nor know how their users interact with the software. Their job is precisely to complete tickets from the product manager. The product manager is the one who should be in charge of UX research and “build a software that solves users problems.” Sure, in abstract that is the mission of the developers too, but in any structured (and hopefully functional) team, product strategy is not what the software engineer should be concerned with.

Developers shouldn't test, they should throw it over to QA who will test it precisely to meet the defined requirements. The Product Manager's job is to communicate the customers needs to the developers/designers and the developers/designers constraints back to the customers. It's up to the developers and designers to understand those constraints and make sure they are communicated back.

It's wild to me that a lot of people consider that SWE need to be knowledgeable in business requirements and interact with clients all day. Just try to imagine construction workers doing the same thing when building a skyscraper. Instead of laying bricks, mortar and beams, now every worker loses 1-2 hours each day asking each stakeholder separately what they want, if they like how it's going so far etc. And then make changes to the layout when the clients ask! What kind of monstruous building will emerge at the end? Edit: if you downvote, at least provide a counter argument. Or is etiquette dead?

They should have a general idea of what they are building and why, in exactly the same way as a construction worker. That doesn't mean they spend all day asking stakeholders what they want. It means that when there is a choice and the stakeholder has to make a decision, the developer should be able to understand some of what the stakeholder is looking for so that they can recommend a direction. Sure, a carpenter is just putting up a wall, but if they're experienced and they see that there's going to be a joist that is going to block some feature, they should be able to point that out to the architect or builder or client.

Absolutely agree, but in practice this means devs are expected to sit in meetings with clients multiple times a week just to make sure everyone is on the same page. This also means that either all the devs on the team are required to be present, wasting time, OR that devs meet with stakeholders individually and knowledge ends up decentralized. And secondly, I think that devs are expected to know WHY "all frobs are percurators" instead of just knowing that they are. Besides keeping up to date with all the tech stack, you are now expected to keep up with all the business details of your client (client which might change in a year or two).

I appreciate the reply. > If upvoting doesn’t require justification neither should downvoting. I disagree, since downvoting is not equal to upvoting. First off, not everyone has the ability downvote (at least on hackernews). Second, upvoting usually means you agree with something, while not agreeing should be reserved to the action of NOT upvoting. This is how most social media works. Downvoting should be reserved for something that should not belong on the thread. Regarding the topic of the discussion, I agree that "builders" should be proactive and knowledgeable about the system that they are building, but the "chief architect"/project manager should be the intermediary between them and the clients, if for nothing other than being a single source of truth.

>Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems. While I agree in spirit, when you reach a certain amount of people working on a project it's impossible. The product manager's job is to understand real user problems and communicate them efficiently to the engineering team so the engineering team can focus on engineering.

No. The product manager has to understand the big picture, but when you're working on a team that big, it follows that you're going to be working on a product big enough that no one person is going to be able to keep every single small detail in their mind at once either. You wouldn't expect the engineering manager to micromanage every single code decision—their job is to delegate effectively so that the right people are working on the right problems, and set up the right feedback loops so that engineers can feel the consequences of their decisions, good or bad. In the same way, you can't expect the product manager to be micromanaging every single aspect of the product experience—their job is to delegate effectively so that the right people are working on the most important problems, but there are going to be a million and one small product decisions that engineers are going to have to have the right tools to be able to make autonomously. Plus, you're never going to arrive at a good engineering design unless you understand the constraints for yourself intuitively—product development requires a collaborative back and forth with engineering, and if you silo product knowledge into a single role, then you lose the ability to push back constructively to make features simpler in places where it would be a win/win for both engineering and product. This is what OP means when they say that "The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected".

If it’s impossible to understand users problems then something has gone horribly wrong.

> Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems. The main benefit of understanding the purpose and real world usage of your software is that you can ask the right questions while planning and implementing the software/feature/bug-fix and that you don't make any wrong assumptions. In a situation where you have conflicting requirements or concerns regarding the change, you'll eventually be hit with "PM knows the product & customer better" or the explicit "your job is to deliver what is asked".

Probably just let them vent until they adjust their habits and just chat with their co-workers, without the need to use this as an excuse. Then, they can enjoy the fast loading times :)

First define who the real customer is. Second define what the real problem is. Third define a solution that solves 80 percent of their problem. None of this is intuitive or obvious. It may not even be technically feasible or profitable.

Everyone's brain builds a model of the world. One of those higher levels of maturity that some people never reach is to realize that when your model becomes incorrect, that doesn't necessarily mean the world is broken, or that somebody is out to get you, or perhaps most generally, that it is the world's responsibility to get back in line with your internal model. It isn't. This is just people complaining about the world not conforming to their internal model. It may sound like they have a reason, but the given reason is clearly a post hoc rationalization for what is basically just that their world model doesn't fit. You can learn to recognize these after a while. People are terrible at explaining to each other or even themselves why they feel the way they feel. The solution is to be sympathetic, to consider their input for whether or not there is some deeper principle or insight to be found... but also to just wait a month or three to see if the objection just dissolves without a trace because their world models have had time to update and now they would be every bit as upset, if not more so, if you returned to the old slow loading time. Because now, not only would that violate their updated world models, but also it would be a huge waste of their time! Thoughtful people should learn what a world model violation "feels like" internally so they can short-circuit the automatic rationalization circuits that seem to come stock on the homo sapiens floor model and run such feelings through conscious analysis (System 2, as it is sometimes called, though I really hate this nomenclature) rather than the default handling (System 1).

The solution is to accept that this isn’t a software development problem, and to remove yourself from the situation as painlessly as possible. If a manager wants to structure a morning break into their employees’ day, they can do that. It doesn’t require a software fix.

> Obviously the proper solution is to adjust your system thermal management / power targets, My point is that I understand the users' complaint and request for a revert, not that I can't address this for my own machines. The proper solution for non-technical people is to ask the expert to fix it, which may include undoing the change if they were never interested in the process finishing faster anyway. I did solve this problem once upon a time by running the process in a cgroup with limited CPU, though I later rewrote my dwm config and lost the command, without caring enough to maintain the fix.

My favorite is the first one, "The best engineers are obsessed with solving user problems." and what I hate about it is that it is super hard to judge someone's skills about it without really working with him/her for a very long time. It is super easier said than done. And it is super hard to prove and sell when everybody is looking for easily assessable skills.

This is why (flawed though the process may be in other ways), a company like Amazon asks "customer obsession" questions in engineering interviews. To gather data about whether the candidate appreciates this point about needing to understand user problems, and also what steps the candidate takes to try and learn the users' POV or walk a mile in their shoes so to speak. Of course interview processes can be gamed, and signal to noise ratio deserves skepticism, so nothing is perfect, but the core principle of WHY that exists as part of the interview process (at Amazon and many many other companies too) is exactly for the same reason you say it's your "favorite". Also IIRC, there was some internal research done in the late 2010s or so, that out of the hiring assessment data gathered across thousands of interviews, the single best predictor of positive on-the-job performance for software engineers, was NOT how well candidates did on coding rounds or system design but rather how well they did at the Customer Obsession round.

When you're not shipping, you're not learning from users. As a result, it's easy to build working, correct, performant code which doesn't fit what anyone actually needs.

You can't learn from this because users always complain no matter what. The trick is they just complain about the last thing they remember being bad, so it's a good sign when that doesn't change, and it's bad if they start complaining about a new thing.

I believe one of the main reasons why Windows 11 is getting so much vitriol is that Microsoft is focusing on customers , which aren't always identical to users. Most of the time, when you buy a Windows-based device, you're not their customer: you're the OEM's customer, and for the OEM, every nickel of expenses counts. On the other hand, direct Microsoft licensees, such as corporate ("enterprise") customers, get much more attention from the company and a significantly better experience.

> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse. There was no beancounter takeover and it never was so obsessed. I worked there from 2006-2014 in engineering roles and found this statement was particularly jarring: "User obsession means spending time in support tickets, talking to users, watching users struggle, asking “why” until you hit bedrock" When I worked on user facing stuff (Maps, Gmail, Accounts) I regularly read the public user support forums and ticket queues looking for complaints, sometimes I even took part in user threads to get more information. What I learned was: • Almost nobody else in engineering did this. • I was considered weird for doing it. • It was viewed negatively by managers and promo committees. • An engineer talking directly to users was considered especially weird and problematic. • The products did always have serious bugs that had escaped QA and monitoring. In theory there were staff paid to monitor these forums, but in practice the eng managers paid little attention to them - think "user voice" reports once a quarter, that sort of thing. Partly that's because they weren't technical and often struggled to work out whether a user complaint was just noise or due to a genuine bug in the product, something often obvious to an engineer, so stuff didn't get escalated properly. This general disconnection from the outside world was pervasive. When I joined the abuse team in 2010 I was surprised to discover that despite it having existed for many years, only one engineer was bothering to read spammer forums where they talked to each other, and he was also brand new to the team. He gave me his logins and we quickly discovered spammers had found bugs in the accounts web servers they were using to blow past the antispam controls, without this being visible from any monitoring on our side. We learned many other useful things by doing this kind of "abuser research". But it was, again, very unusual. The team until that point had been dominated by ML-heads who just wanted to use it as a testing ground for model training.

Every previous job I've had has a similar pattern. The engineer is not supposed to engage directly with the customer. I think there are multiple reasons for this, but they are mostly overlapping with preserving internal power structures. PM's don't want anecdotal user evidence that their vision of the product is incomplete. Engineering managers don't want user feedback to undermine perception of quality and derail "impactful" work that's already planned. Customer relations (or the support team, user study, whatever team actually should listen to the user directly) doesn't want you doing their job better than they can (with your intimate engineering and product knowledge). And they don't want you to undermine the "themes" or "sentiment" that they present to leadership. Legal doesn't want you admitting publicly that there could be any flaw in the product. Edit: I should add that this happens even internally for internal products. You, as a customer, are not allowed to talk to an engineer on the internal product. You have to fill a bug report or a form and wait for their PMs to review and prioritize. It does keep you from disturbing their engineers, but this kind of process only exists on products that have a history of high incoming bug rate.

Engineers have a perception that most other roles are lesser and if only they were allowed to be in charge things would go better. I certainly used to be this way. When I was an engineer I used to regularly engage directly with customers, and it was great to be able to talk with them one to one, address their specific issues and feel I was making a difference, particularly on a large product with many customers where you do not normally get to hear from customers much. Of course once these customers had my ear, the feature requests started to flow thick and fast, and I ended up spending way too much time on their specific issues. Which is just to say that I've changed my views over time. In retrospect, the customers I helped were ones that had the most interesting problems to me, that I knew I could solve, but they were usually not the changes that would have the biggest impact across the whole customer base. By fixing a couple of customers' specific issues, I was making their lives better for sure, and that felt good, but that time could have been used more effectively for the overall customer base. PMs, managers etc should have a wider view of product needs, and it is their job to prioritize the work having that fuller context. Much as I felt at the time that those roles added little value, that was really not true. Of course agreed that all the points made above for PMs, managers, support having their reasons to obstruct are true in some cases, but for a well run company where those roles really do their job (and contrary to popular opinion those companies do exist), things work better if engineers do not get too involved with individual customers. I guess Google might be a good example - if you have a billion customers you probably don't want the engineers to be talking to them 1:1.

> Engineers have a perception that most other roles are lesser Do they? I always felt I was at the bottom of the chain. "Moving up" means leaving engineering and going into management. > and if only they were allowed to be in charge things would go better. Could this be an oversimplification? Engineers understand how the product is built because they are the ones building it. And sometimes they are exposed to what other people (e.g. product people) have decided, and they know a better way. As an engineer, I am always fine if a product person listens to my saying that "doing it this way would be superior from my point of view", somehow manage to prove to me that they understood my points, but tell me that they will still go a different direction because there are other constraints. Now I have had many product people in my career who I found condescending: they would just dismiss my opinion by saying "you don't know because you don't have all the information I have, and I don't have time to convince you, so I will just go for what you see as an inferior way and leave you frustrated". Which I believe is wrong. Overall, I don't make a hierarchy of roles: if I feel like someone is in my team, I play with them. If I feel like they are an adversary, I play against them. I don't feel like I am superior to bad managers or bad product people; I just feel like they are adversaries.

I think he has a point. These power structures exist for some good reasons as well. The opposite thing (engineers engaging directly with customers) can eventually lead to customer capture of your engineering org. You shouldn't have a small group of existing, noisy customers directly driving your engineering to the detriment of other existing or future customers. Microsoft had customer capture institutionally: the existing big corporate customers were all that mattered. It lead to rebooting Windows CE into Windows Mobile way too late to make a difference, for example. But it also meant that backwards compatibility and the desire to ship Windows XP forever were sacred cows. There are also nasty games that can be played by soliciting negative feedback for political advantage. Dysfunction can exist with any structure. It's probably best that there's some small amount of direct user feedback as well as the big formalized feedback systems, at least so that one is a check for the performance of the other. If the user engagement team says everything is good, but there are massive Reddit threads about how horrible the product is to work with and the engineers know it could be better, it's time for engineering to start addressing the issues alongside feedback to the user engagement teams.

Agree that this can be an issue but to clarify, I was finding bugs or missed outages, not gathering feature requests or trying to do product dev. Think "I clicked the button and got a 500 Server Error". I don't think random devs should try and decide what features to work on by reading user forums - having PMs decide that does make sense as long as the PM is good. However, big tech PMs too often abstract the user base behind metrics and data, and can miss obvious/embarrassing bugs that don't show up in those feeds. The ground truth is still whether users are complaining. Eng can skip complaints about missing features/UI redesigns or whatever, but complaints about broken stuff in prod needs their attention.

An org can always go too far in the opposite direction, but this is not an excuse to never talk to the customer. The latter is much more likely, so the warning to not get “into bed” with the customer falls flat. This is a common pattern here. Alice says 0 degrees is too cold, I prefer 20C, Bob chimes in “100C is too hot, it’ll kill us.” Ok, well no one said or implied to crank it to one hundred.

every customer complaint is N customers lost who don't say anything "the biggest impact" isn't knowable so a bird in hand is worth more than whatever might be in the bush

If you have M customer complaints, and each one risks a differently-sized N customers... you better try to triage that vs just playing whack-a-mole with whatever comes to a random engineer first. I've never seen engineers plow through a bunch of 0-or-1-customers-would-actually-churn-over-this papercuts because it was easy and it feels good - the customer mentioned it! i fixed it! - while ignoring larger showstoppers that are major customer acquisition and retention barriers. Nothing is knowable in only the same way that plans are useless but planning is essential.

> Every previous job I've had has a similar pattern. The engineer is not supposed to engage directly with the customer. Chiming in to say I’ve experienced the same. A coworker who became a good friend ended up on a PIP and subsequently fired for “not performing” soon after he helped build a non technical team a small tool that really helped them do their job quicker. He wasn’t doing exactly as he was told and I guess that’s considered not performing. Coincidentally the person who pushed for him to be fired was an ex-Google middle manager. I’ve also seen so commonly this weird stigma around engineers as if we’re considered a bit unintelligent when it comes to what users want. Maybe there is something to higher ups having some more knowledge of the business processes and the bigger picture, but I’m not convinced that it isn’t also largely because of insecurity and power issues. If you do something successful that your manager didn’t think of and your manager is insecure about their own abilities, good chance they’ll feel threatened.

> The engineer is not supposed to engage directly with the customer. I don't know if companies have finally stopped pretending to be "agile"; but if not, this is such a clear demonstration of how they are anything but.

Where I work we regularly bring in engineers to talk to clients directly. Clears up a lot of confusion when there’s something technical a PM wouldn’t understand. We still like to have a filter so a client isn’t trying to get the engineer to do free work. Having engineering isolated is pretty bad IMO.

The sad thing is it doesn't have to be this way. I worked on an internal tools team for a few years and we empowered engineers to fix user issues and do user support on internal support groups directly. We also had PMs who helped drive long term vision and strategy who were also actively engaging directly with users. We had a "User Research" team whose job it was to compile surveys and get broader trends, do user studies that went deep into specific areas (engineers were always invited to attend live and ask users more questions or watch raw recordings, or they could just consume the end reports). Everyone was a team working together towards the same goal of making these tools the best for our internal audience. It wasn't perfect and it always broke down when people wanted to become gatekeepers or this or that, or were vying for control or power over our teams or product. Thankfully our leadership over the long term tended to weed those folks out and get rid of them one way or another, so we've had a decent core group of mid-level and senior eng who have stuck around as a result for a good 3 years (a long time to keep a core group engaged and retained working on the same thing), which is great for having good institutional knowledge about how everything works...

There are very good less-cynical reasons. I've also seen companies with the opposite problem, where the engineers constantly shoot down real, important feedback brought by customer support in order to preserve the superiority of engineering over support. If you have ten engineers and even just 100 customers, you have a very high number of conversational edges. Good luck keeping things consistent and doing any sort of long-term planning if engineers are turning the output of those conversations directly into features. "Engineers talking to customers but not making any changes" would be more stable, but is still a very expensive/chaotic way to gather customer feedback. Additionally, very few of those single engineers have a full knowledge of the roadmap and/or the ability to unilaterally decide direction based on some of the customer feedback or questions. "Will this get fixed in the next two weeks?" "Will you build X?" etc. You don't want your customers getting a bunch of inconsistent broken promises or wrong information. The best-managed orgs I've seen have pretty heavy engineering and user experience in their product and support orgs. You need people in those roles with knowledge of both how it's built AND how it should be used, but you can't continually cram all that knowledge into every single engineer. A startup should start with the builders talking directly to the customers. But at a some point, if successful, you're going to have too many people to talk to and need to add some intermediaries to prevent all your engineering time going to random interrupts, and centralization of planning responsibilities to ensure someone's figuring out what's actually the most important feedback, and that people are going to work on it.

On the contrary, the best products are typically built by the users of the products. If you are building a product you don't use, it will be worse than if you used it. Users should be everywhere, in and out of engineering.

It is an almost universal fact that dealing with retail customers is something that is left to the lowest paid, lowest status workers and often outsourced and now increasingly left to LLM chatbots. While you obviously can't have highly paid engineers tied up dealing with user support tickets, there is a lot to be said for at least some exposure to the coal face.

> While you obviously can't have highly paid engineers tied up dealing with user support tickets, You obviously can, that's one of the more visceral way to make them aware of the pain they cause to real people with their work, which sticks better, or simply serves as a reminder there are humans on the other side. There are even examples of higher paid CEOs engaging, we can see some of that on social media

If an engineer talking to users is considered problematic, then it is safe to assume, that Google is about as fast away from any actually agile culture as possible. Does Google ever describe itself as such?

Having only ever worked for startups or consulting agencies, this is really weird to me. Across 6 different companies I almost always interfaced directly with the users of the apps I built to understand their pain points, bugs, etc. And I've always ever been an IC. I think it's a great way to build empathy for the users of your apps. Of course, if you're a multi billion dollar conglomerate, empathy for users only exists as far as it benefits the bottom line.

> User obsession means spending time in support tickets That's really funny when Google's level of customer support is known to be non-existent unless you're popular on Twitter or HN and you can scream loudly enough to reach someone in a position to do something.

Thanks for sharing your valuable insights. I am quite surprised to learn that talking to customers was frowned upon at Google (or your wider team at least). I find that the single most valuable addition to any project - complementary to actually building the product. I have a feeling a lot of the overall degradation of software quality has to do with a gradual creep in of non-technical people into development teams.

Almost nobody else in engineering did this. What you described is the job of a product manager. Are there no PMs at Google?

There are, and often times they're stuck in a loop of presenting decks and status, writing proposals rather than doing this kind of research. That said, interpreting user feedback is a multi-role job. PMs, UX, and Eng should be doing so. Everyone has their strengths. One of the most interesting things I've had a chance to be a part of is watching UX studies. They take a mock (or an alpha version) and put it in front of an external volunteer and let them work through it. Usually PM, UX, and Eng are watching the stream and taking notes.

Xoogler here. When you get to a company that's that big, the roles are much more finely specialized. I forget the title now, but we had someone who interfaced with our team and did the whole "talk to customers" thing. Her feedback was then incorporated into our day-to-day roadmap through a complex series of people that ended with our team's product manager. So people at Google do indeed do this, they just aren't engineers, usually aren't product managers, frequently are several layers removed from engineers, and as a consequence usually have all the problems GP described.

I've had the pleasant experience of having worked for PMs at several companies (not at Google) who were great at their jobs, and advocated for the devs. They also had no problem with devs talking directly with clients, and in fact they encouraged it since it was usually the fastest way to understand and solve a problem.

I think it is more the point that the users for his job were external developers. The role is inherently user facing and user focused. I don’t think anyone was trying to say he wasn’t a developer just that his job wasn’t to directly develop products

Addy's users have been developers and Google has been very responsive in the past. I was usually able to get a hold of someone from teams I needed from Chrome DevTools and they've assisted open source projects like Node.js where Google doesn't have a stake. He also has a blog, books and often attended conferences to speak to users directly when it aligned with his role. I agree about the general Google criticism but I believe it's unjustified in this particular (admittedly rare) case.

You are onto something there, if you mean, the design roles being taken over by the people who are not techies - like the POs. But if you just refer to UX being designed for mobile devices - that is not an excuse for an even worse UX on the mobile. If anything I would have expected more effort put in there, given how many more issues the limited screen estate can cause...

As a developer I took the writer's point to refer to "users" generically, so that even if you work on some internal tools or a backend layer, you still have users who have to use your app or consume your API and there is a lot of learning possible if you communicate and understand them better.

Probably the users he is talking about are not the end users like you and me. It is one team using the tools/software of the other team and so "users" for that other team are the members of the first team.

I see it differently then UX at all. I find the need for better customer support 1000x more pertinent to helping users.

And how are they supposed to do it if users did not add proper 2FA (and backup those recovery keys)? Even banks are struggling to authenticate folks. For a longtime in EU people with 3rd world passports cannot create accounts easily. Google cannot connect identity of a person to email address easily. Or they need to create CS - that will authenticate passports? And hundreds of countries, stolen IDs? Nay. > The thing is that at scale your edge cases are still millions of people > never seem to be capable of handling the other parts that come with it Same thing with govts. If you go to driver license. passport or any govt office then there will one person with some strange issue.

That is a great point too. For a company which effectively does not have a customer service, how can they claim to be obsessing about helping users at all?

Hell, in my experience they often don’t even help ad customers that are having issues that prevent them from buying ads.

> First do it, then do it right, then do it better. Get the ugly prototype in front of users. Great, give users something that messy, horrible and not fully functional. Customer who spend big for production environments are exploited to "be the outsourced QA"

It's ok if the users are internal

> 3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one. > First do it, then do it right, then do it better. Get the ugly prototype in front of users. Write the messy first draft of the design doc. Ship the MVP that embarrasses you slightly. You’ll learn more from one week of real feedback than a month of theoretical debate. > Momentum creates clarity. Analysis paralysis creates nothing. I've met Addy and I'll be generous, but strong disagree here, and this really shows a huge blind spot in how software is being developed today that hurts everyone. There aren't two extremes between "theoretical debate" and just shipping the first crap you can slap together. Software engineering will never become a real discipline when industry keeps ignoring the lessons of every other field of engineering: gather some requirements first. Want to know what users want? How about asking them? What about doing some research on what tools they are using now (or not) and finding out what's wrong with them. What about doing a user study? What about analyzing competing and previous products? How about then drawing up a list of things that say what the thing will do ? You can keep the list short, sure. Build a prototype (maybe for internal use)? Sure. No need to have every piece of functionality there. But there's an enormous blind spot here I'd be remiss to point out. Back in the shrink-wrapped software days, back when products took months and sometimes years to develop, man, people really planned out what they were going to build! And I'm not just romanticizing that era--there was a lot that could go wrong, and many misses--but tons of software developed in that manner sticks with us today, not just the designs and usage patterns, but big chunks of the code too. It's not all legacy cruft; people actually thought about what they wanted to build, and then laboriously built and tested it--with crappier tools, longer build times, and many disadvantages like huge teams, crappier communication, and a whole lot less computational power. There are other things in this list that are good advice, but I felt like this cannot possibly be the whole truth to 14 years of experience. In other words, please don't just ship your crap to us the first time it functions.