[general1726]

Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints.

The moment you have stubborn engineer who knows better than PM and user, it is really difficult to get anywhere. However if you will put such engineer into line of fire from a users that's suddenly not engineer's friendly PM trying to tell the engineer that this is wrong, these are frustrated people who would like to skin engineer alive as a punishment for using his "awesome" creations! That induces fear, but absolutely also crushes his ego, because somebody is berating product of engineer's genius like it would be a retarded hamster.

From my perspective, it is not about showing that PM is an idiot, it is about humbling your engineers. Their ego will grow again and this exercise will need to be repeated.

[hvb2]

Assuming your PM is for product manager not project manager.

I would think the engineers usually get their kick out of making things fast or easy to maintain. If you have a product manager and the customers hate the product, how is that the engineers fault?

I've built a couple useless features that I wouldn't want to use and couldn't explain how to use. But if you have a product person, they get to design is BECAUSE they're in the line of fire.

That's a comfortable position to be in as an engineer, except that you sometimes have to build things more than once.

[zamadatix]

There are two separate problems, and they aren't mutually exclusive, but this post seems to be specifically about the latter case (if one believes the story, of course):

- The PM(s) are bad at listening to customers or turning customer feedback into a focused set of requirements.

- The engineer(s) are bad at following the requirements or going back to the PM(s) when the requirements aren't clear.

In the first the PM(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product.

In the second, the engineer(s) can just lack understanding of what the product does or interest in why customers use it, can be overconfident in their ability to "see what the customer actually wants", or just actually want to build something else but are assigned to this product.

In either case, it results in the product not fitting the customer needs. I think there are better ways to solve either gap than just having the engineers join sales calls to hope it works out, but I suppose any approach is better than letting the problem sit.

[pyman]

Lots of product managers have never studied product development. You'll find philosophers, designers, physicists, even musicians in the role. Many have great people skills, but little understanding of customer service, building products, or scaling a business. And funnily enough, those are all real careers and degrees.

The result, which you often see in companies with 300+ employees, is that engineers have far more experience building products than their PMs, what engineers usually lack is knowledge of the customer and their pain points, and a roadmap that leads to successful outcomes. In other words: a real product manager.

It's not enough for PMs to throw around cliches like "I represent the customer" or "the product has to be built around customer needs" if they don't understand how to actually build and ship software.

Last year I dug into this and found it's not unusual. Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. But most have little to no background in business, marketing, economics, or product development. Some companies go even further and promote an engineer with project management experience to Head of Product. And, of course, people in those roles tend to hire others who look like them, with similar experience. One day their CEO realiseS their product isn't selling, customers aren't happy, or engineers are left to figure out what to build.

To put it in perspective, imagine a company making a lawyer their Engineering Manager and asking them to build an engineering team. What are the chances they'd do better than a computer scientist or an actual engineer? Pretty slim. Sure, there are exceptions, but what usually happens is their engineers aren't motivated and complain about the lack of coaching, vision, purpose, and the poor quality of their tools, processes, code, and work environment.

Bottom line: companies need to audit product leadership roles as a priority and figure out who's really in charge of the product. Run an internal survey to check whether your CPO, Director, Head of Product, and Product Managers have studied business or have actual expertise in it. If not, you're in trouble.

[ivan_gammel]

I support every single word of this comment. Good product managers are unicorn masters of discovery and delivery who are so rare that they climb up quickly in corporate hierarchy to strategic positions leaving holes in product operations. I have seen products running A/B tests without understanding how they work, designing UI sketches without any knowledge of UX, pushing features to roadmap based on a feedback of a single user etc. Maybe it makes more sense to abandon this role instead of fixing it and split the required skills between UX designers, business analysts, marketers, engineering and project managers etc.

[pyman]

I think the role of Product Manager should be renamed Customer Manager to avoid confusion and conflicts of interest. Some companies like Airbnb tried switching to Program Manager, but that only adds to the confusion.

Right now, the Product Manager is seen as the CEO's delegate, making sure the product follows business strategy, while the Engineering Manager is the CTO's delegate, making sure the product follows technical strategy. One represents business the other represents technology. But IMO since both are building the product together, the title Product Manager creates competition instead of collaboration.

The software needs the customer just as much as the customer needs the software. That's why I think the roles of Engineering Manager and Customer Manager make more sense, working together to build the best product possible. The product isn't managed by one side, it's managed by both.

However, the real problem isn't the role title, it's the qualifications of the person in the role. Companies don't hire lawyers as Engineering Managers, so why do they hire musicians as Product Managers?

[ivan_gammel]

>Business strategy

>Customer Manager

That sounds weird. Product managers do not represent customers interests, they represent business value which is not always in making all customers happy. E.g. conversion optimization brings no added value to customers, so it’s not a great name choice. If the role defined as it us now, „product manager“ is the most appropriate name.

[jbmsf]

I have worked with so so many ineffective product managers. The good ones are indeed unicorns.

Even when you have good ones, they can't scale up to all of the things that I'd want them to own, meaning that engineering fills a lot of gaps.

This ends up being uncomfortable and necessary. I'm still learning how to make it work.

[pyman]

The best PMs are like mini-CEOs, and many of them go on to become CPOs. But there's a lot of confusion in the software industry about what the role of a PM should be. For example, I see companies putting too much emphasis on usage metrics, while very few focus on the far more important skill of asking the right questions. PMs look at dashboards to make informed decisions, but most of them aren't even asking the right questions. And they don't know if the questions they're asking are the right ones, because they have no real knowledge of product development, just a bit of experience which is limiting. That's what happens when engineers, designers, or musicians end up in PM roles, reacting to data or using it to validate their own or someone else's assumptions.

The real problem, I believe, starts with companies hiring anyone with people skills as a PM. They don't understand their role and responsibilities, it's common to hear PM say "I own the product." But that's not really true. According to successful founders and CEOs, they are the only ones who truly own the product, and that's an important point for leadership to establish. PMs thinking they own the product creates power struggles with leadership, engineering and design, while a title like "Customer Experience Manager" makes it clear the role is about representing the customer's needs, aligning them with the CEO's vision, and making the right trade-offs.

Business people with knowledge and experience always put the customer at the centre and focus on aligning customer value with business value. In other words, if you're the CEO of Uber and your PM isn't driving a taxi once a week, then, IMO, you hired the wrong person.

[timr]

> Last year I dug into this and found it's not unusual. Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. But most have little to no background in business, marketing, economics, or product development. Some companies go even further and promote an engineer with project management experience to Head of Product.

I was right with you until the last sentence of this. As an engineer-turned-PM who is still very much technical, I can count on one hand the number of technically competent PMs I've known in my life, and have plenty of fingers left over. Having experience developing products can easily be a liability, because while delivering software is important, you're mostly expected to be an advocate for the business, which means that you live in the world of corporate politics and can't be perceived as too in the tank for the tech staff.

What I see is the exact opposite of what you've described: the PM that gets ahead is invariably someone with a background in business or marketing, and the technical background is deemed almost irrelevant. If you spend too much time focusing on technical issues, someone swoops in with the theater of "data-driven decisions" and "rapid iteration" -- you can justify virtually anything by cherry-picking statistics, and it's always possible to criticize the development speed of a team when you don't involve yourself in the details -- the role quickly becomes about spinning a compelling story to upper management.

Basically, a huge percentage of PMs understand little more than the first few chapters of The Lean Startup.

[Infernal]

I think the comment you're replying to agrees with you - it makes more sense with the last two quoted sentences swapped. I could be wrong but this interpretation seems consistent with the rest of the comment.

"Many software companies hire smart people as CPO, Product Director, or Head of Product because they have leadership skills, people skills, and some knowledge of the industry. Some companies go even further and promote an engineer with project management experience to Head of Product. But most have little to no background in business, marketing, economics, or product development."

[pyman]

I was saying that many companies already make a mistake by putting unqualified people in senior product roles, and some go even further by making the bigger mistake of promoting an engineer with only project management experience straight to Head of Product.

[AznHisoka]

>> Many have great people skills, but little understanding of customer service, building products, or scaling a business. And funnily enough, those are all real careers and degrees.

Where would people skills rank then in your hierarchy for product managers?

[pyman]

People skills matter for product managers, but they come after customer and product experience, business and product strategy, and execution and delivery. Otherwise you just end up with a nice PM who doesn't know how to move the product forward.

[BobbyTables2]

Would also be really nice if companies selected CEOs with a deep understanding of the core business.

[hinkley]

> I would think the engineers usually get their kick out of making things fast or easy to maintain

Is your company hiring? Because I've spent 30 years being this engineer and nearly everyone looks at me like I've got horns growing out of my head.

That's not where most engineers find their job satisfaction, more's the pity. And they think they know better than users. There's a reason UX has been around for at least four decades longer than DX. Developers think both are made up.

[Nadya]

If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor?

I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't designed for. They might even clob several different tools together in an unholy abomination to get it to do what they actually want instead of having a tool built to do precisely what they want (and once that tool has been built - people will inevitably misuse it to do things other than what it was designed for and then complain about its poor UX for doing those things).

[uberduper]

> If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor?

Playing along with this analogy, what I think we see a lot of in product development is the customer going to the PM and saying they need the cone to have a cover. The PM and the customer iterate over the specifics of the cover. PM goes to the engineer and tells them the cone needs a cover that meets x, y, and z requirements. Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists.

[dgfitz]

> Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists.

That’s the kicker. They know what the customer _wants_ not what they _need_

The number of times a Jr engineer has asked me “how do I accomplish task X in technology Y, it’s really important!”

I always, always ask “what problem are you trying to solve. Not once in over 15 YoE has the solution been to use X.

A good PM doesn’t say “this is what the customer needs” because most of the time the fucking customer doesn’t actually understand what they need.

The engineer knows that holding the ice cream cone upside down means they’re trying to use the product in a way it was never intended, so they push back.

A good PM would ask “why do you want to hold the ice cream cone upside down, customer?”

“Oh well we don’t actually want to hold it upside down, we just get frustrated that sometimes when we put too much ice cream on/in the cone it falls out. So if you can make the cone hold the ice cream while upside down, the problem is solved!”

“Oh, so what you actually need is a bigger cone that can hold more ice cream?”

“Oh, yeah that would work too”

meme about Spider-Man facepalming, where Spider-Man is the engineer

[uberduper]

My point is that by letting the customer define the solution rather than explain the problem, nobody knows they're even trying to hold it upside down. The why of it all is lost in some PM / Engineer power struggle that usually results in ice cream cones having covers (and a happy customer).

[dgfitz]

As a sw engineer, I’m going to tell our customer that the thing they claim they want they do not need.

Because I’ve done this enough times, they’ll listen to me and we won’t waste time on it.

You should try it, instead of designing soggy ice cream cone caps.

[boticello]

And thus the tub was conceived. By someone who was watching people wrangling with cones.

[selbyk]

Unfortunately tho, it also suffers the same huge design flaw: hold it upside down, ice cream hits floor. =(

[fuzzy_biscuit]

And thus, the milkshake was born. And it was good.

[wahern]

> I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't designed for.

Isn't that the point? In the story the engineers weren't designing a tool well-suited for the customers, but for whatever abstract scenarios they had in their head. In the open source world it's more reasonable and common to design a tool not predicated on the predominant models and workflows. And every once in a awhile those experiments result in something very valuable that helps to break predominant paradigms. But in the commercial space solving customer's immediate problems in a manner that is intuitive for them is paramount.

[Nadya]

> In the story the engineers weren't designing a tool well-suited for the customers, but for whatever abstract scenarios they had in their head.

A joke exists about how developers will never be displaced by AI because that would require clients and/or project managers to accurately describe what they want the AI to build. On one hand that is extremely egotistical of developers. On the other it is also factual.

To my understanding of the story the developers had designed what was being communicated to them by someone who described what customers asked for and not what the customers actually wanted or needed. Nothing to do with what the engineers thought customers wanted and everything to do with what project managers had expressed to the engineers about what customers wanted. Speaking with the customers directly gave them a better idea of what was actually being asked for. So they built that instead.

My takeaway from the story is to fire the project manager. Not to make devs call clients.

[wahern]

Product and project managers can have similar issues of perspective as engineers, chasing trends in the industry or losing the forest for the trees (feature checklists, etc). But, yeah, having devs talk directly to customers can be problematic. If you give a customer a direct line to an engineer, sometimes they can monopolize the engineer's time (they feel they can leverage an "inside" contact) or skew their priorities. Having engineers work closely with tech support is a good middle ground, such as by fostering 1:1 relationships with support or even fielding tech support tickets themselves (tech support tickets have more finality than, e.g. sales support issues). That way they can get a broader perspective on pain points and potential new directions. It can really help refine a product beyond what can be achieved by lobbing feature and bug tickets over a fence or through formal group meetings (which often can be either too structured or too chaotic).

[sillywabbit]

God forbid an engineer should have an opinion on UI/UX.

[neilalexander]

I have long believed that the biggest issue here is that engineers and power users generally have a much higher “pain threshold” when it comes to poor or complex UI/UX. They are not always the best people to judge how or if less experienced users will tolerate or adapt to those patterns. It’s fine to have opinions but they must be prepared for them to be challenged. Even better if they can invite others to challenge them, which is essentially what talking to your users achieves.

[matheusmoreira]

> engineers and power users generally have a much higher “pain threshold” when it comes to poor or complex UI/UX

I don't think that's entirely accurate. We tolerate steep learning curves if the result is an increase to our power. That's why we are power users.

Vim, for example. Some of us put effort into learning it because it's a powerful and efficient editing language that will enable us to easily accomplish hard things.

Caring about the system itself and being willing to put effort into it are what separates power users from normal users. We don't do this because of masochism, we do it because we want to increase our power.

Normal users want the system to just do what they want without any thinking or effort at all, as though it was a highly specialized tool for their exact task rather than a powerful programmable general purpose computer.

Personally I don't care at all about how "less experienced users will tolerate or adapt". This unceasing focus on the wants and needs of normal users frequently hinders us. Developers typically reduce the complexity and feature set of a piece of software in order to turn it into something a normal user can deal with. We want more power, not less.

Normal users don't really matter unless they are directly paying our salary. We should all favor ourselves unless we're getting paid to focus on someone else.

[slipperydippery]

The two biggest causes of major UI problems I see are:

1) Exactly what you wrote: power users don’t even realize they clicked through five things in ten seconds any one of which would have derailed a weaker user, because they’re so used to bad UI that it’s almost invisible to them.

2) Zero care given to what’s most natural for the platform, for cost of development & maintenance, or what’s easiest for the user, when (bad) designers and (bad) “product folks” get involved and are way too into the wrong kinds of “consistency”, especially brand and cross-platform consistency (yo, I’m not sure it’s worth spending extra money fucking up contrast and platform norms on your inputs so your fucking radio buttons are “on brand” or whatever, like, I’m deeply skeptical of the actual business value of that kind of thing, though I can see the PowerPoint presentation value… and that’s why it happens)

[ijidak]

But is it an informed opinion?

Every human has an opinion on practically everything. But has that human put in the effort to justify pushing that specific opinion?

In this case, is the opinionated engineer humble enough to realize that using software in their day to day life does not equal using software in our customer's context?

[rcfox]

Ultimately, you need to decide who your target user is. Do you want to cater to the lowest common denominator, or do you want to want to make something power users can customize to fit their workflow?

Neither answer is necessarily wrong, you just need to make a choice.

[AnthonyMouse]

> you just need to make a choice.

This fallacy is at the heart of the failure of modern software.

Making things work for the median user is almost entirely about defaults and intuitiveness. If everybody is sending messages all the time, there should be a conspicuous button for sending messages.

Making things work for power users is about allowing those defaults to be changed. It's fine if this is five deep in a menu somewhere. It's fine if there is an option for "advanced mode" that opens up a bunch of menus that are otherwise hidden. It's fine if this requires you to write your own filter rules etc., as long as that's available. What's not fine is to make the limited interface the only interface.

Simple things should be easy and complex things should be possible.

[koliber]

> Simple things should be easy and complex things should be possible.

I love this.

Building on this thought: When you are starting to build something, you have very limited resources. Focus only on making simple things easy and forget everything else. Once you have product market fit expand into making complex things possible. This applies to 90% of all products.

[thfuran]

Those goals are far less at odds than you seem to be implying.

[gattilorenz]

One of UX principles is exactly trying to do both.

My mom can use gmail, but she doesn’t even know about its hotkeys and accelerators, or Labs and whatnot

[sillywabbit]

If I use the product, I'd expect that feedback to get the same weight as any other customer. And not be dismissed because it came from a 'technical' person.

[spacecadet]

Using? Are you paying?

[sillywabbit]

If you're building a website that is accessible to the public at no cost, I don't see the distinction.

[spacecadet]

The issue is that software engineers most often strike a balance between passive aggressive and overly opinionated... Its a shit mix if you ask me- very frustrating personality to work with.

[rTX5CMRXIfFG]

Isn't that the same as UI/UX people being generally clueless about how to build applications for the very platform for which they are designing? Designers and product managers constantly have to be guided about the logical and the structural constraints of their target platforms, to be given workarounds, to be taught how to logically divide their reusable components so that they can build their dream design system which, by the way, always fights the platform's native design system.

It's totally fine to have an opinion on UI/UX if it is informed by cognitive psychology and other relevant HCI subfields, in the same way that it's OK for UI/UX to push for designs so long as they are also informed by business and engineering.

[GlassOwAter]

That’s the attitude he’s talking about!

[matheusmoreira]

> People around Desktop Linux could write a complete book about dismissing user's complaints.

On Linux we enjoy flexible systems that empower us to change the things we don't like all by ourselves without any need to involve any "project managers" at all.

And it's completely fine if Linux systems are built around the needs of programmers and power users. It's not like normal users are paying us. Linux users should focus exclusively on themselves and their own needs.

[anbotero]

While PMs have their own share of quirks to work around with and your comment doesn't say they have no faults at all, I wholeheartedly agree with you here. I've worked as a developer, QA, systems operator, and a bunch of other positions. Holy cow, we are all full of ourselves (PMs included), but the disdain of a lot of developers towards the end user (sometimes PMs fault) is incredible. A bunch of nerds ignoring common people use cases and abilities. And it keeps happening and most still don't recognize what's happening.

I've worked as a Manager so I've had to deal (and collaborate) with this kind of misunderstanding, but it truly gets tiring when developers complain about users trying dumb things (for developers) over and over again, yet they themselves have learned nothing from previous encounters with this phenomenon and complain instead about stupid users (or PM, or company, or whatever).

[ccakes]

I kind of think this is correct but not for the reason you think. To most engineers, users are the annoying thing on the other end of a ticket. They “don’t know how to use the product properly”.

I’ve also had great success dropping engineers directly in front of customers. I think it’s just because it humanizes the person behind the ticket

[godelski]

I think you're right. Similar to the article's title, a useful thing is dogfooding. But where this can go wrong is because conversation is engineer to engineer (not exclusively) is that the takeaway can be "Oh, I was holding it wrong" instead of "this was not as intuitive as I thought, how can I fix that?" I know there's backend vs frontend arguments[0] but I think backend needs to be conscious about front end. When we write backend it is easy to just focus on making things work but we're a few steps back from typical (or targeted) use cases.

Classic problem with us eningeering types, right? When you're in the weeds it is easy to see the differences. Humans are always biased to forget how difficult it was to learn something, judging on level of current (subjective) difficulty. For me a big change in framing came through Linux. I'd convince my friends to use it and then as the years went by I saw how much easier it became to do so. Now, for the most part it is much easier for an average person to use. There difference isn't "holding it wrong" so much as "it's hard to hold" (or "it's hard/unintuitive to hold correctly"). Even just with the more recent rise of TUIs. Even us terminally terminal types are loving the new TUIs and ultimately that is a frontend thing. It's just frontend for backenders, allowing us to stay in the environments we are efficient in, maintain our power and flexibility, but also get some aesthetics (which has functional utility! I bet you use syntax highlighting, and not just because it is pretty).

There's a strategy to writing backends that I think helps both backend and frontend: write flexible code. It draws from the unix philosophy, where functions (or small programs) should be containerized or focused. Then the complexity happens by putting the things together (there's a hierarchy to this). Helps write backend code so it is easier to maintain, reduces repetition, allows for quicker feature development, and ultimately makes it far easier to read. It's a little more work up front, but it sure pays dividends. It helps front end people because ultimately they are towards the... *front end* of that hierarchy. Makes it easier for them to pull pieces together, wrap things, and communicate with backend types.

Honestly, I think the biggest roadblock to this strategy is the constant push for rushing. Why is there always time to do things twice but never enough time to do things right? It all depends if we're running a sprint or a marathon. A sprint is all about speed, but a marathon requires a lot of strategizing. A marathon requires some sprinting, but you can't sprint the entire thing. We like to drop sayings like "don't let perfection be the enemy of good" but truth is it's not about perfection, it is about different ideas of what is "good enough." Which, is ultimately an issue of communication.

[0] I'll still argue backend is more important ;) because that's the foundation. Your building can't stand, let alone be pretty, if it doesn't have a solid foundation and skeleton. All that is invisible though. Maybe that's why these arguments occur.

[andrekandre]

  > Honestly, I think the biggest roadblock to this strategy is the constant push for rushing. 

ironically, giving more time upfront can make things faster because people now have time to make a proper implementation, so you have less rework/qa cycles...

[godelski]

I don't think it is ironic, but makes perfect sense. It's about the marathon strategy.

I think another important part of "running a marathon" is having excess time. It is hard to predict disaster, but you can prepare for it. You don't want the exact number of lifeboats so that each passenger on the ship has a seat on a lifeboat. You need excess because in a disaster it is likely a lifeboat will fail. The lucky thing with time is that if you finish ahead of schedule you can just go onto the next thing. It's always better to finish ahead of schedule than behind. But if you always predict to be on schedule you're more likely to fall behind because there's more ways to fall behind than get ahead.

[andrekandre]

  > It is hard to predict disaster, but you can prepare for it.

yes, you need slack to deal with inevitable surprises and delays that will occur so that you can actually make it 'in time'

  > But if you always predict to be on schedule you're more likely to fall behind because there's more ways to fall behind than get ahead.

this is counterintuitive for a lot of people and especially for managers under pressure from above

running without slack means every bump in the road adds a delay which makes the manager's troubles even worse when they have to report the inevitable delay (which leads to a negative spiral of rush-and-delay)

[godelski]

  > running without slack means every bump in the road

I think you ran into maybe a good analogy here (spitballing). To go fast on a bumpy road you need slack, in your shocks. You have to absorb those bumps. But if you have no shocks you just rattle apart.

Sure, a rally car isn't as fast as nascar, but which environment are you in? Super smooth road with only left turns and is built to allow you to go as fast as possible? Or literally anything else.

[klingon33]

This story of whittling down the product to meet the needs of the user as grepped from several sales calls assumes that a small sample is statistically representative (and it’s not) and assumes simplification always makes for a better product (and it doesn’t).

When I ask 15 users for their input, only 3 will speak up, and their needs and views don’t fully overlap.

Photoshop is a great example of a product that was extremely complicated and difficult to use but dominated the market for many years.

Microsoft has continually made updates to its products over the years, making it basically do the same thing but with unnecessary and frustrating changes, and people keep buying it.

Yes, UX is important, and A/B or similar evolutionary testing is important. Yes, devs tend to overcomplicate things. But, there’s no magic simplification bullet.

[wordofx]

PMs don’t help make good software.

[hinkley]

Don't try to tell them that.

[evanjrowley]

>somebody is berating product of engineer's genius like it would be a retarded hamster

Where can I find this hamster and is it available for adoption?

[rendaw]

The fact that Jobs wasn't an engineer shows this clearly isn't just an engineering problem.