Andrew Thompson in Engineers of Addiction, a fascinating profile on the psychology of slot machines:

Game [slot machine] designers are charged with somehow summoning the ineffable allure of electronic spectacle — developing a system that is both simple and endlessly engaging, a machine to pull and trap players into a finely tuned cycle of risk and reward that keeps them glued to the seat for hours, their pockets slowly but inevitably emptying.

In other words, their job description is to make people win just enough so that they come back long enough to lose big. I just can’t wrap my head around that.

Thomas Schranz writes in Product / Market Fit is a Trap:

Obsessing about product/market fit is a huge waste of your time. Yes … waste of your time. There … I said it again. […]

As I said above you don’t want to focus on product/market fit. You want to focus on building a great product and on getting it into the hands of your customers.

First, let’s talk about tone. I’m pretty averse to absolute language like “it’s a trap” and “it’s a waste of time.” Things are rarely that dramatic, but I guess nuance doesn’t play very well on the internet. This is also the problem I have with proclaiming that “flat design is evil.” A good designer won’t let an aesthetic trend get in the way of affordance and visual hierarchy. A good designer will work within the constraints of a particular aesthetic to accomplish their (and their users’) goals.

But I digress. On to the substance of the post…

If you read Marc Andreeessen’s entire post on Product/Market fit, you’ll see that Thomas and Marc’s views are not in conflict at all. Marc might use slightly different language, but his definitions of product and market are very similar to what Thomas proposes above (my emphasis added):

The quality of a startup’s product can be defined as how impressive the product is to one customer or user who actually uses it: How easy is the product to use? How feature rich is it? How fast is it? How extensible is it? How polished is it? How many (or rather, how few) bugs does it have?

The size of a startup’s market is the the number, and growth rate, of those customers or users for that product.

Marc is using VC terms, but his meaning is clear: build a great product, try to get more people to use it (or as Thomas puts it elsewhere in his post: focus on product and distribution). It is up to us as product designers and product managers to figure out how to make that happen. Jobs to be Done, Personas etc. are fantastic ways to do that. But those methods are not opposing theories of startup success, as Thomas suggests. They’re a continuation (the how) of Marc’s Product/Market fit framework.

Steven Hoober has some great guidelines for touchscreen design in Fingers, thumbs, and people:

Most of all, within what you can control: Always design for hands, fingers, and thumbs.

And remember: You don’t design for iPhone or Android, for cars or kiosks, for Web or apps, but for people. Have empathy for users and respect their choices, their ways of working. Account for the limits of their lives, their environments and their abilities.

Even when your implementation is constrained by technology, avoid designing for pixels or code; always consider what effects your work will have in the real world, when people look at, hold, and touch the screen.

An interesting counter-argument to the #noestimates movement—and a call for reasonable software development estimates—on the Clever PM blog¹. From In Defense of Estimates:

From a business perspective, some level of estimation is absolutely required, so that judgment calls can be made as to priorities of execution and communications within the company and to customers. We need to have some level of understanding of whether something is “bigger than an elephant or smaller than a breadbox” so that we can deploy other parts of the organization appropriately. “It takes as long as it takes” is not useful for tactical or strategic planning within any organization.

Jamie Hodari makes the point that the recent blowback against office spaces (and open office plans) might be slightly overblown. She asks, Is Working Remotely Sapping Your Creativity?

A creative work life requires social relationships and serendipitous interactions. It requires contending with ideas you don’t agree with. It requires getting up and moving around. As a result, it’s becoming increasingly clear that for many people, working at an office isn’t a relic of a pre-digital age, but a vital element in reaching their creative potential.

Bumping into coworkers, chatting in hallways, sitting down over lunch, a day at the office results in dozens of interactions everyday. The result, shown both anecdotally and in statistics, is more creativity and greater effectiveness. For instance, in one study tracking the behaviors of a sales team of a pharmaceutical company, “when a salesperson increased interactions with coworkers on other teams . . . by 10%, his or her sales also grew by 10%.” Cross-functional, seemingly spontaneous interaction facilitated greater effectiveness on the part of workers–something that would not have been possible had sales representatives been working from their homes.

Christina Wodtke writes about the intersection of design and business in Why Design Needs Entrepreneurship (and Entrepreneurship Needs Design). This is a particularly nice summary of the three major startup handbooks in high circulation these days:

Steve Blank said you should talk to your customers as you develop your offering. He said there were no answers in the building, you must go out into the world if you want to make something people want.

Eric Reis said you should build small things, test them, learn, then build the next thing until you find successes.

Alex Osterwalder said you should look at all aspects of the business and design them collectively to assure a successful ecosystem. While all three hold a distinctly user-centered design approach, Osterwalder is the first to state it unambiguously, using design tools and innovation games throughout his book and calling them that. It is a designed book, in every sense of the world, and it was written in collaboration with a group of beta readers.

All three, at their hearts, are user-centered designers. They just happen to design business.

This is a great call for designers to care more about the business of design.

Some interesting perspectives from Dharmesh Shah in Why Your Startup Should Ignore Your Onboarding Experience (For Now):

Great user onboarding makes users say, “WOW, this is awesome,” and recognize that your product is a must have experience. But these WOW moments don’t come easy. And the mechanics by which you onboard users is just a small part of whether or not they fall in love with your product.

The more substantial part of the equation is the value your product delivers to your user: something in their life that must get easier, faster, cheaper, more productive, more fun, etc. because of using your product. Otherwise, why would they switch?

And that’s the difficult part to create. That’s the part that requires customer development and experimentation. It requires you to test your assumptions, to pivot, to try new things.

His recommendation is to do completely manual onboarding at first—contact every new user to find out why they starting using the product, email users who become inactive, etc. It might not scale, but it provides invaluable feedback at the inception of a product. Once you get to about 100 active users, Shah believes you know enough to create a great in-app onboarding experience. Food for thought!

David Travis has a good overview of collecting and analyzing usability testing data in How to record and analyze user research observations. This definition of an observation is particularly important:

Here’s the golden rule: an observation is a record of something you see or hear. Novice researchers often treat their opinions on what they like or dislike as observations. But your opinions aren’t observations — and neither are suggestions for new features or insights on how to fix usability issues. Don’t try to interpret the things you observe or fit things into a solution. That comes later.

The best observations come from watching real users do real tasks, and being as true as possible to the concrete details of what you see. You can either do this in the wild (with a field visit) or simulate actual use in a lab environment (with a usability test).

When making notes, just jot down observations, don’t try to solve the problem right there. The only thing I would add to David’s advice is that I try to mark important observations as I start to notice trends throughout the day, like so:

Now, if I could only figure out how to read my own handwriting, that would really help.