The Day I Met Jeff Bezos | Hacker News Reader

The Day I Met Jeff Bezos

blog.highfive.com

69 pointsmike247748 comments

A couple of things irk me about this article, but that could simply be due to the incredible vagueness.

>"He paused another moment and then said, “I know that’s not your plan because it can’t be done. What is your real plan?”

He told us he wanted to see a new version the very next day. The request didn’t seem to make much sense. In fact, to this day I’m not sure what the product will be used for—but we dropped everything else we were working on and scrambled to get the demo done in time."

So the author worked (presumably quite hard) on something, received dismissive feedback that didn't make any sense, didn't question any of it, scrambled to re-implement on an uninformed guess for the next day then (surprise) got slapped around again.

That honestly sounds more like a loyalty/submissiveness test of some sort than anything else.

Ideally, that meeting was a great opportunity to challenge the man and earn some respect from him or possibly lose some for him depending on how it plays out.

>"He wasn’t thinking about the feature; he was thinking about the customer experience."

What is wrong in the culture / education of engineering that people have to be taught this after they start working?

"What is wrong in the culture / education of engineering that people have to be taught this after they start working?"

I wonder how many universities make their engineers or developers actually build something for an outside or even internal customer.

Strangely, vocational folks deal with customers quite a bit in learning and learn to think in those terms. Nothing like having to redo the doors on a cabinet or rerun some plumping to make you think first.

I took an experimental class last semester where we teamed up with a design student to build a website for a local non-profit/small company. The technical aspects of the class were less than satisfying but taking a product through the entire life cycle (even though it was a small project) was a great learning experience.

I'm pretty sure they made it a full on elective class next semester.

> I wonder how many universities make their engineers or developers actually build something for an outside or even internal customer.

For my final year full-year Software Engineering project with 16 team members we built and delivered a software product for an external customer - a big name Software company you've heard of.

It was an awesome project, working so closely and directly with the external end customer.

Which university was that?

Swinburne University of Technology, Melbourne Australia.

As a bonus, the Bach. of Software Engineering is accredited by the Australian Institute of Engineers.

> I wonder how many universities make their engineers or developers actually build something for an outside or even internal customer.

Don't most?

At my alma mater, students in either Telecommunications or Comp Sci majors were required to do a capstone project their final semester for an outside client/customer. They made a big deal about the demo day for it and it was always a cool event. Considering my school was a large public school that isn't known specifically for its computer science/IT, it seems strange that more schools don't do this. It seems like most CS friends from other schools had the same experience as well.

It's really too bad if some people don't get a chance to do this. There are countless things during that project that were good learning experiences, but they would have been awful if it had happened when I actually had a real job. I can definitely say that project determined a lot of my future plans.

"Don't most?"

It doesn't seem like it, and I would bet it has something to do with local population size and budget.

What are your plans that were determined by that project and how do they differ from your prior plans?

My school was notorious for being heavy on theory and most of the engineering curriculums included 'product projects', more than a decade ago.

(No idea what they do now, but I would guess they would have shifted further in that direction)

"I wonder how many universities make their engineers or developers actually build something for an outside or even internal customer."

Why would a university do any such thing?

University is the place and time to learn things that no business has the time or skills to teach you. Serving customers is exactly what you should learn at work.

> What is wrong in the culture / education of engineering that people have to be taught this after they start working?

Whatever "customer experience" means is specific to an industry/company, not a universally agreed upon term. For Amazon, which is largely B2C, UX is critical. For other industries, delivery time may be more important. There are such things as tradeoffs, and in some cases, it makes sense to prioritize things other than an awesome UX.

Expecting to define or predict customer experience as some sort of regression model seems to miss the point nearly as completely as possible.

As I see it, it's as simple as taking the time to think as the customer.

Not much I can add, except, "Where was this Jeff Bezos when a customer wanted to quickly flip around in an e-book on the Kindle?"

> What is wrong in the culture / education of engineering

...or, does the typical engineer's needs and tastes differ so much from the typical customer's that most engineers simple cannot not see the latter? For example, many of my friends in tech could not and still cannot see why so many consumers prefer iOS to Android given how much more customizable or "tinker-able" the latter is. The ones that get it the best are the ones that play tech support to many non-techie family members.

Engineers brains just work and see the world differently than most people.

>"The ones that get it the best are the ones that play tech support to many non-techie family members."

Right.

As I've related on HN before, I believe a pivotal point very early on in my career was seeing technology through the lens of my aging mother.

It completely opened up my perspective about tech in service of people.

I take your observation and my experience as evidence that this empathy and understanding can certainly be learned - it's a question of how to teach students and convince them that it matters.

>"Engineers brains just work and see the world differently than most people."

Sure, I get what you're saying, but I wonder how much of the negative side of that is self-fulfilling in teaching and ultimately being an engineer.

I'd like to think we can be excellent hammers without treating everything as a nail.

Would have been nice to know the product in question, so he could relate concrete examples of how Bezos is meticulous in his eye for detail and customer experience. I mean, it'd be neat reading an article talking about the first prototyped version of MayDay, and how Bezos laughed about it in the first meeting, transforming it to what it's become today.

I worked on one of a flotilla of related projects at Lab 126 - none of which has seen the light of day in toto, but parts of which have escaped into shipping projects. There's a reason he's reticent - amazon (in the personage of lab 126), more than any other company I worked with, is insane about internal security and rumor control.

Is this the way we kiss our bosses "ego" now? Hay Jeff--since you are so concerned with the customer experience; vet your resellers more carefully--especially the ones that have dozens of complains about wrong orders, or counterfit goods? Put away the flying toys, get the ego in check, and go back to what made you a billionaire--selling the right product, at the right price. I know it's not glamorous, or stimulating anymore, but it's what the customers want.

Reminds me of this Yegge story: https://plus.google.com/110981030061712822816/posts/AaygmbzV....

thanks. the OP is such a tease with all the missing details. long form ftw.

"In fact, to this day I’m not sure what the product will be used for—but we dropped everything else we were working on and scrambled to get the demo done in time"

I wanted to know how other developers deal with this phenomenon when you effectively don't know what your end product is or what it will be used for ?

Generally flail around, make assumptions, and scramble to fix things after the fact. It rarely works very well, but you get your pay check.

Yeah, at Amazon they wouldn't tolerate that forever...

Who's the narrator here? Mike, Adam, someone else? http://imgur.com/gdR785r,iaaBddd#1 http://imgur.com/gdR785r,iaaBddd#0

It's an interesting story to relate, but it seems to be missing details that could really flesh it out, and it ended abruptly.

Yeah, would have liked to see specific examples of features he picked apart, revisions that were made, etc. That would make this article much more valuable.

You can't expect actual content in these blog posts. It's vaguely self deprecating promotional post with a high-value name drop in the title crafted to get the link to the front page.

With one important takeaway: focus on the customer, not on personal engineering goals.

Therein lies the beauty of these types of posts. They allow the reader to fill in the gaps with their own conclusions without the author risking actual opinion.

>The request didn’t seem to make much sense. In fact, to this day I’m not sure what the product will be used for—but we dropped everything else we were working on and scrambled to get the demo done in time.

>The next day we returned and presented the feature to Bezos. I knew instantly that he wasn’t satisfied. For two minutes we stood in silence as Bezos picked our feature apart. He spoke as if he had already built the product himself.

How could this engineer even hope to solve a problem if he didn't understand it? Jeff Bezos spoke as if he had already built it because he was probably the only person who understood what he wanted. The entire story sounds like an utter waste of time.

Does that mean Bezos doesn't care about AWS? Not likely.. Probably because he is not the target user.

Care you explain how you arrived to that conclusion?

I don't follow, what are you getting at?

It means Bezos can't entirely relate to the AWS customer (which isn't retail, but a developer or technical organization), or fixing it isn't nearly as easy?

That's a loaded accusation, but its the best I can come up with as a response.

Per Yegge's post about Amazon's use of interfaces everywhere internally (https://plus.google.com/+RipRowan/posts/eVeouesvaVX), he/Amazon is probably the prime user.

Bezos must feel like he is surrounded by morons.

indeed. same goes for all the Jobs stories.

nobody under these people seem to get anything right. they have to be torn to shreds and spoonfed by the great lords to "see".

Occasionally, some shine and go on to make their mark in the industry. Yegge has been mentioned in this thread, but Spolsky as well: http://www.joelonsoftware.com/items/2006/06/16.html

Compared to Bezos, they probably are morons. That doesn't mean they aren't probably still well above the average person in terms of skills/intelligence.

Or, he's a smart man with a lot more experience than a typical kid fresh out of college.

How do you get to present to Bezos "a few month" after joining as a graduate?

Feels like the article was an afterthought written around a nice title.

So my question is how do you view the software you created from a customer's point of view? As someone who creates the software there must be a certain creative blindness we experience.

I mean I'd love to create a software, revert my brain back to the idea state and look at the software again.

What is the process of Jeff Bezo's? How does he "rip apart feature by feature"?

The way I do it is try to envision the dumbest, most impatient, penny-pinching DICK HEAD out there possible, and make him happy.

Any of the following statements destroy customer experience: - "The customer should understand that at this point..." - "The customer already did X, so its clear that Y..." - "Waiting 20 seconds isn't that unreasonable." - "Its in the terms and conditions so we are covered." - "What do they expect? We can't message that perfectly every time."

Don't. Fucking. Compromise. Make the ass holes happy. You will have surpassed everyone else's expectations by miles.

Also, if making "the dumbest, most impatient, penny-pinching DICK HEAD out there" fills you with disgust, disdain, rage, sadness, etc. it might be time to reconsider your career choice. As much as we may wish it, the users never go away.

this is what I've been doing for a long time. However, it sometimes forces me to create more features than I can chew because in my mind, it's a guy paying $20 a month and wanting A-Z features.

Keep in mind its often the quality of the features that matter more than the number of them. No one is going to use a feature that is sometimes very fast and sometimes take 20 seconds and doesn't work 20% of the time.

Reply on news.ycombinator.com