1/ For whom a product is designed is an interesting question. Sounds easy…most say they know but… Software people love to “build for myself” or “solve my problem” — those become products and companies—it can work. But there are challenges to listening to yourself and team?

It is not uncommon for engineers and designers to start out believing “if we can’t please ourselves then we can please many more” when it comes to making a product. “If I like it, then others will too”.

In fact this “for me” is even codified in a “favorite” book of programmers, “The Fountainhead”. “My ideas are mine. Nobody else has a right to them except on my terms. Those who need them must take them my way or not at all.” —“Howard Roark” (Ayn Rand)

In a 1990 Harvard B School case study on the creation of Microsoft Word (a pretty successful product) one of the engineers on the team (using the term design—there weren’t really designers yet) said this (case - hbr.org/product/micros…)

A big reason for the “audience of one” is also the feeling of listening to too many people or getting too much input will cause a product to be “designed by committee” which no one likes.

Even if the whole product is not engineered for an “audience of one” we all know how common it is to tweak, add, or enable many features that are about pleasing individuals or the company. This has three big challenges stemming what is potentially a “mono-culture” product dev.

These might seem really obvious and many people might just blow off this discourse and say “we listen to customers” or “we have research to make sure we are in touch” and so on. This isn’t a straw-person debate as most every product has some mono-culture risks.

First, software products are built by software professionals even if the customers do something really different than software—just reality. Maybe you make software for lawyers, or rocket control software, or just a spreadsheet for MBAs. The lens of “s/w eng” is just not right.

While the Word team was busy designing for an audience of one the Excel team made of many of the same “types” had to go figure out banking. Even most engineers can imagine “writing papers” so it worked early on—spreadsheets were a whole different challenge.

That challenge led the product team early on to embrace a lot of external learning and feedback into the product. What was always amazing to me as a newbie engineer was how the people who knew *how to use* the product best were customers and sales and not the eng team, example:

I was once trying to make a histogram for some VC++ data. I walked XL hallway in search of a dev to help me. No one knew how to make one. One even stepped through the code/debugger trying to figure out how. No luck. Best person to ask? One of the front line phone support techs!

Lesson: when you’re building sophisticated products for sophisticated users, chances are they will end up better users than the makers. How weird is that? Software development is a “mono-culture” that turns out to be pretty different than most other professions.

If the first challenge is mono-culture of s/w, the second challenge is the company/team culture. All products are products of a team. Many amazing products exist because teams have unique ways of working. But sometimes, especially as you mature, that uniqueness is a liability.

The term “dogfooding” (while gross) is a popular way to describe using your own product. Most every product built is dogfooded in some way, unless they are highly specialized. Dogfooding is an incredibly powerful technique…until you realize your company is unique.

One of the most interesting aspects of dogfooding is that you’re usually the very first customer. This means your behavior is often based on the earliest views of the product. Customers get the product later (and later) and start from scratch. Features, needs, approaches differ.

As your organization grows, you might even see internal resistance to changing “dogfood” processes to use new features. Conversely, you might be much quicker to change to new features than your customers. Then the “old stuff” might get “neglected”.

Importantly, how you use a product, one you built, might be a reflection of your corporate culture. For example most SV products value “transparency”. Not surprisingly many “old school” companies have a tough time with that and want data protections, visibility rules, etc.

Your company might be “all in” in using your own product to do work. Customers have existing systems or methods to accomplish things. Ex: XL used XL for *everything* proving how insanely cool/flexible it was. But customers, while perhaps amazed, didn’t see the tool the same way.

Did you know that a spreadsheet is a much better word processor than a word processor? After all, a word processor is just a spreadsheet with one cell.

Lesson: The culture of the team can be an asset when dogfooding a product. But you need to be sure that your team culture is not dominating the design and prioritization of features unless you are sure your culture matches that of your customers.

Third challenge is the mono-culture of early customers. It’s not uncommon for early companies to have customers all drawn from a single “cohort”—an industry vertical, geography, or size. For example, often incubators are often the first customer of each other’s products.

Ex: All early adopters use g-suite and are from your incubator—bvious limitations in diversity of inputs. Early product lifecycle there’s real tension between depth and breadth. You may just over-focus on what turn out to be a pretty similar group of customers.

Lesson: Diversity in early customers is incredibly important. That’s almost always easier said than done, but nevertheless it should be a goal.

Most everyone wants to make a product that is (a) something they really want themselves and (b) doesn’t require all the complex and messy work of the noisy inputs of the real world and diverse customers.

Often it is too easy and low friction to prioritize yourself, your company, and an early set of too-similar customers. It takes a lot of extra effort to strike a balance. // END

PS: If no one has ever solved a problem you have, then sure solve it for yourself first! Example: Microsoft Exchange (now 365) email. Client/server email didn’t really exist anywhere (Lotus Notes was “different” enough). Until MS used it, no one thought it would work.

Microsoft Mail (en.m.wikipedia.org/wiki/Microsoft…) was created before Exchange to solve that "communications" problem. Regards from a 1995 ex Msft'ee ;-)

And neither were first in their class. Even FirstClass, massively used around macs and still in use today, did the client/server thing in the 80s. Exchange and msmail (like lotus) smartly leveraged corporate users to boost adoption.

Steve you nailed it right here. This is the holy grail of any product design, not just software twitter.com/stevesi/status…

I’d say that listening to customers is quite complex/difficult, while listening to oneself is fast and clean; so hence, albeit a larger, blinder bet than listening to customers, i.e. 90% of startups die. Still, listening to oneself, albeit more expensive, is better than no try.

After working in engineering (Quality Assurance) & Product Management, in startups and public companies (e.g. #AAPL #CA #CSCO) over the last 20 years, I've noticed a decline in user focus and an increase in team hubris. "We know better." User empathy appears rarely unfortunately.

(No comment)

So well said... thx

This is a key tenet in quality design research/ethnography, etc.

I'd guess across verticals / industries? As well as use-cases and personas? To learn about the problem spaces and evaluate opportunities? As well as recognize overlaps and hard problems?

And while you learn still focus and go after one? Or iterating towards one minimum overlapping solution with optimally just one product + one marketing?

This point of view gained a lot of traction in Japan.

There’s a whole interesting story about how the team learned about this and then built new features in Word for authoring tables (“table pencil” was the description when building the features). Incredible product dev learning from Japanese customers. Huge win.

“the” not “a” story (that you know but others on the thread don’t know).

A chief exec at a retail company I worked with in the 90s used Lotus 1-2-3 as his word processor. EA had to convert his spreadsheet letters to WordPerfect to print properly though.

Preaching to the choire of our financial department ... Bullets/outlining everything in a cell ...

Rich text within cells was a big innovation at the time :)

I think it would take a table-centric-markdown-editor in javascript to get that level of innovation again ...

Of course! It’s as easy as 1-2-3!

It’s not. ToC, page breaks, foot notes, captions, floating images, etc

Although I agree with some of your points a spreadsheet is not a WP and shouldn’t try to be - also although diversity is good there is nothing wrong with specialist tools for vertical or other non diverse markets - it’s a matter of focus and intent

I remember when people were so obsessed with Lotus 123 that it was used as both a Wird Processor and a Presentation program!

Mind blown. #offtowritefirstgreatcubistnovel

This could be a horrible example but my first thought led to gaming. Blizzard was one of the first companies I remember that was building sophisticated games for competitive gamers. As great as their Lead devs were, we would always get better.

My thoughts exactly. Whole speedrun genre is a result of sophisticated users learning the game to the point of bending it to achieve the end result

Zero day exploits kind of fall into that category

PSS or the test org were the better choice of who to ask as to how to use XL.

Of course I was totally going to say test org but for too many now that role requires explaining what was super unique back then and why you knew what to do. I won’t name names from the dev hallway :-)

It was pretty funny through — Rick dropped into the debugger to try to figure out the way the old histogram add-in worked :-)

The more I learn about product management, the more I agree wit this. Design for your target user. Not yourself or what you think is cool.

I worked with a couple of such people…

When they’re right they’re right.

Composer Witold Lutoslawski said he wrote for himself, to guarantee that at least one person would enjoy it. Nevertheless, he regarded composing as "fishing for souls", a search for listeners like him for whom the music would resonate. Works for software, too.

Either you haven't read the book or you do not understand Howard Roark

So why do you design products that enable control for bankers instead of building products that solve problems other than "how to make a lot of money"? Money is a byproduct of making great products. Focusing on the money will only lead to mediocre products and foolish minds.

In the scientific world, you often see the mind of the programmer over riding the mind of the user. Scifinder's web addition removed critical functions, for example.

Fantastic insight here. Always essential to toe the line between what you want to build and what your target customer wants/needs. Thanks for sharing. However, I’m a little confused on what you call dogfooding—how would you define it?