Product sense for engineers

[andyvan-ph]

Summary

Product engineers need product sense. How do you develop / improve it?

This would be a practical guide with some tips for honing your product sense / the types of experiences you should seek out to help develop it.

Ideally, this would be from someone with some authority on the topic. Could be an podcast topic, or a guest post on the newsletter.

Headline options

• An engineer's guide to product sense
• What is product sense and why do you need it?
• In the age of AI, engineers need product sense
• Why engineers need product sense (+ how to develop it)

What (if any) keywords are we targeting?

n/a

Outline (optional)

draft headings / questions you want to answer

[daniloc]

We could wait around for someone extremely prominent on this, or I could do it, with some drop-in quotes from some of the best product engineers in the business, whose workplace I have successfully infiltrated.

Bonafides:

• I built and designed multiple apps that reached the front page of the App Store (as in, Apple's editorial team blessed them as worthy exemplars of the platform)
• When I built Hipmunk for iOS, Apple put it on demo devices in their physical stores
• It was entirely upon the rock of my product sense that I got into Silicon Valley in the first place

Pitch:

Design equals credibility

• People do not trust janky things; jank suggests a lack of care, and that erodes trust
• You don't have to be a full-on designer to develop a good-enough sense of design to avoid jankiness
• Start by learning what jankiness feels like, and become its worthy adversary

Visual design tips to avoid obvious jank

• Grids make things look tidy and deliberate; absence of alignment to a grid suggests jank
• Keep your typography lean and focused. Don't use too many weights, don't combine more than two families (maybe three if you need to handle monospaced content)
• Be careful with colors. They're great as accents and for grabbing attention, but don't assume that you can map a bunch of different meanings to them; users will not always associate what you expect with a given color.
• Design is a thing you can learn. Here are a few books. You can also learn from your favorite software. Don't be shy about stealing the best strategies.

Understanding affordances

• Affordances help your product communicate to users: this is what you're looking at, this is how it works, this is what you can do with it
• Affordances are affected by trends. You have to keep looking around to see what software affordances have currency
• Try popular products and learn which affordances they use

Always be prototyping

• Software is expensive: it takes time to build, it takes time to understand previously-built software to change it. Which means once you've built software that sort of works, it has inertia. It is resistant to change.
• Therefore: avoid building the full-version of a user-facing feature until you've validated it with a prototype
• Prototypes are great: they're cheap so you don't feel bad throwing them away, and they're fast so you quickly get feedback on your direction
• Feedback from real people trying to use an interface you have prototyped can save you many wasted cycles.

You have to play with lots of things

• At the risk of repeating ourselves: you can't be an island on this stuff. You need to develop a sense of taste: what is nice, what is not, and the way you get there is by playing with a bunch of things
• Develop a reflex for understanding why you like something, so that instead of just copying the superficial design of other products, you can use their underlying wisdom to make your own stuff better
• Keep screenshots and recordings of products you use
• EVERYTHING is in-scope here, from cereal boxes to websites in other industries, to video games. Lessons are everywhere for those willing to learn.