Balancing My Budget with My Desire

In my work on Nickel I want to avoid giving the same old tired advice that a lot of financial advisors give — manage your money well, then go out and life your life with whatever money is left. That’s not how most of us live.

For example, my family is planning on going on vacation this year. Does that mean we have excess cash because every other area of our financial life is tied up with a neat bow? Definitely not. But after working all year we need that time off, in our case to play on the beach, go swimming, and just enjoy being a family.

I was thinking of this because we’re about to replace one of our cars that is coming off lease. It would primary act as my wife’s way of getting to work, so she’s taken the lead on testing driving and figuring out what she wants. She narrowed it down to a few options:

  1. Buy the car we have if the loan payment is within our budget
  2. Buy a new car within our budget
  3. Buy a used car within our budget

We’re lucky to be in a golden age of automobiles where there are plenty of cars, used and new, that are attractive, affordable, and reliable. But many options can make it complicated. I love car research; my wife does not.

But “The Budget” is a constant factor there. And so my thought is we can just make that a constraint. And as I know from my design work, constraints actually make it easier to get things done because you can focus your creativity. In this case, we can focus on our desire, on what makes us really happy. So before getting lost in details and financial options I find it helpful to just set a simple financial constraint and then focus on fun.

So I proposed another approach to my wife:

How about you pick the model that will make you the happiest and then we’ll find one that fits our budget?

She replied,

Good call :)

Raise the Bar

Perhaps the single most useful thing a manager of a design/development team can do is to raise the bar of quality. By extension, I think this also holds true for clients of design agencies.

By ‘raise the bar’ I don’t simply mean saying, ‘This isn’t good enough’ or ‘work harder’, or this…

Raising the bar sounds simple but it’s not. To do it properly, the manager/client must first understand what is possible given their budget and timeline and resources. Once you know this, you can see when the output is short on quality and you can do something about it.

Second, you need to have a sense of what is currently keeping people from falling short. Is it a personality conflict? Too many meetings? Not enough coordination? Rushing into execution without generating enough good ideas?

Third, you have to have the guts to deliver the message in a constructive way. The Steve Jobs yell-at-people method worked for Steve Jobs, but unless you work at Apple it may not work for you. In my experience good people want to do well. They want to feel good about their work and themselves. They want awesome samples in their portfolio. So appeal to their work ethic, paint them a picture of how awesome the future is going to be when things are different, then set the bar of what you expect.

In sum:

  1. Understand what is possible in your situation
  2. Figure out where the obstacles are and remove them
  3. Constructively set the bar higher for the team by inspiring them

Docker and Containers Summarized

Just as container ships can carry more cargo because they use a standard form factor for storing the cargo, software containers can run more apps on each server by using a standard way to share the operating system without all the wasted overhead of virtual machines.

How?

  1. Containers bundle together all the pieces you need to run the app into one package.
  2. Containers make it easy to deploy apps to local servers and the cloud.
  3. Docker makes it easy to create containers.

Also check out Steven J. Vaughan-Nichols’ What is Docker and why is it so darn popular?.

Channeling my inner Edna Mode

Whenever I feel downtrodden and powerless I channel my inner Edna Mode and imagine it’s me, not Elastic Girl, she’s whacking over the head…

Confront the problem!

Fight!

Win!

Why I’d Love to See Graded Interaction Design Problems

One reason I love bouldering is that it’s game-like. No matter how much experience a climber has, we’re all at a certain level with certain climbs (they’re actually called “problems”) that currently challenge us. It’s like playing a well-crafted video game: the levels you’ve finished are easy, the levels ahead of you are frustratingly hard, but the level you’re currently on is a good match of difficulty for your skill level; and you can feel the flow.

8wng7

I recently started learning a new programming language and I find it similarly game-like. Every new technique is a new challenge. Every new algorithm is a new challenge. The easy stuff is boring, the crazy theoretically stuff is frustrating, but the next chapter in my book is just right.

And like video games, in bouldering these problems are codified. So I can say, “I can do all the V0’s in this gym, and I’m working on the V1’s” and other climbers know something about my abilities.* Codified problems exist elsewhere too. Here’s some to help people improve their skills playing Go.

I’d love to see graded problems for interaction design. They would make it fun to solve problems, alone or socially, and communicate to each other our level of ability. “But Victor,” you might say, “interaction design problems don’t have a defined solution like a boulder.” Actually the boulders don’t either. People can solve the same problem different ways, but there are rules everyone must follow that give the game useful constraints. As long as you follow the rules and get to the top you’ve solved the problem. Some climbers are more elegant than others, and the same would be true in interaction design.

* The Moonboard is like graded problem-meets-Github, a single wall with over 800 bouldering problems contributed by various route setters.

Published
Categorized as Teaching

Reader Reviews #6/7: “eye-opening….thoroughly researched”

Why We Fail is available in eBook form at O’Reilly and all the reviewers there gave me 5 stars! Yay!

Paul in Austin writes:

The case studies alone provide an very interesting read to anybody who has some interest in technology in general.

Each case study has been thoroughly researched with plenty of references. The author also provides video clips to help the reader visualize the user experience of the discussed products.

In addition to user interface developers or designers, product managers and architects will also benefit from the methods for avoiding future UX failures described in the second half of the book.

BOTTOM LINE Yes, I would recommend this to a friend

Ken in Hoboken writes:

Too many books focus on success but I feel the best way to learn is by studying failures.

Prior to reading “Why We Fail”, the only other book I read along the same lines was “Billion Dollar Lessons: What You Can Learn from the Most Inexcusable Business Failures of the Last 25 Years” by Carroll & Mui.

I am an engineer, not a designer, but I often consult on projects where no UX person is hired, forcing me to assume that role in some fashion. I found this book to provide great insights that I would not have otherwise considered.

For example, as an engineer, I focus on meeting the user requirements, but the case study on the failure of the Microsoft Zune music player (Chapter 5) demonstrates how much more powerful the user experience is over the feature set.

I found it an eye-opening revelation in Chapter 9 that Microsoft’s many expensive failures is due to its practice of sweeping mistakes under the rug and never sharing experiences with their product groups.

Chapter 7’s discussion on ethics is a valuable addition to the material.

I highly recommend this book.

BOTTOM LINE Yes, I would recommend this to a friend

Good Design Can Make the Elevator Pitch Futile

I had a five-minute conversation with an angel investor last week and described the product I’m working on. His response: “Similar things are being done by bigger companies with giant marketing budgets, so you’ll need a very clever marketing idea to succeed. What is it?”

There was an uncomfortable pause. On one hand, I haven’t thought up any great marketing ideas yet and wondered if that was a hole in my plan. On the other hand, I was pretty sure this investor and I had very different perspectives on product development, but I didn’t have the language to succinctly express that gap.

I did understand what he meant. A few years ago I managed a large online dating service. We radically updated the design and added great features, but it was the online marketing that kept the revenue coming in. Why? I believe that while the design was good, the product wasn’t positioned to differentiate it from the competition. By contrast, if you design a product that’s different and more exciting than the competition, like the Anki DRIVE, there will be a lot more free media exposure and word of mouth to complement paid marketing.

My downfall, I think, is that I was trying to tell this investor about the product rather than show him. If my new and improved positioning is a result of product design, I need to show the product. For example, if I verbally described the Anki DRIVE as, “a racing game that combines an iOS app with physical race cars” that’s sounds mildly exciting. Watching the video is so much better…

Agile Ain’t Wishy Washy

As I write this there’s a group of about 15 developers and designers standing near my desk in a heated but constructive argument about how to check the design is right before the code heads off to QA.

Occasionally the dichotomy of agile vs. waterfall is raised, and sometimes “agile” is used as a euphemism for “flexible” as in, “well, there was an update in design document X, and we’re agile, so you should be able to integrate that.”

If there’s one thing I’ve learned from doing agile it’s that agile ain’t wishy washy, i.e. it’s not really some sort of flexibility nirvana. Any software development process relies on firm lines drawn around what, when, and how the work gets done. Otherwise, shit don’t get done.

Yes, agile is better at responding to change. But it is effective, somewhat counterintuitively, because it responds to change with a high degree of rigidity. For example, if the stories aren’t written in a way that makes it clear to developers how to code a feature and how to test it, it doesn’t get accepted into a sprint. Once stories are accepted into a sprint nothing else can start until the next sprint. And so on. When I first encountered all this rigidity I thought the developers were acting like self-involved prima donnas. Actually, they’re just enforcing the rules that make the process work.

Agile responds to change, not wishy washiness.

Published
Categorized as Agile

Startup Legal Straight Dope

A benefit of being a speaker at Failcon was getting an invitation to a talk hosted by Anit Guha of Orrick Legal. Here’s some of his wisdom that I noted down:

  • When choosing a name use the uspto site and a 3rd party search service
  • Avoid incorporating in California; use Delaware C Corp. Not only because of the company-friendly laws in DE, but because everyone incorporates there so everyone is familiar with the legal aspects involved.
  • Founder vesting: vesting important if someone leaves. Typical is four years with a one year cliff, maybe some acceleration too. Can backdate the start of vesting if significant work was done before company was formed.
  • Worker classification: consultants vs employees; employees involve more overhead. But you must follow legal definition, state and federal laws when bringing someone on (you can’t avoid the employee overhead if the person is actually working as an employee).
  • Invention assignment – very important that everyone signs and agrees that ideas and inventions belong to the company; it’s pretty broad, it’s negotiated individually
  • Use offer letters for everyone
  • Use release agreements for involuntary terminated employees. They can refuse to sign; you need to pay them to make it enforceable.
  • Investor “finders” must be a registered broker dealer, otherwise you can’t pay them for that service.
  • Rule 701 disclosure obligations, options valued over 5 mil in 12 month period should be disclosed.
  • Only raise from accredited investors.
  • Taxes at acquisition can lead to a liability if you’re not careful.

RealNetworks and The Trap of Binary Thinking

While I was researching my book Why We Fail: Learning from Experience Design Failures I spent some time reading about people’s experience with RealNetworks, particularly the RealPlayer, and wondering if they were worthy of inclusion in the book, particularly the don’t be evil chapter. At that point there was no smoking gun, no hard evidence that Real intentionally did the wrong thing.

But this week a story was published which confirmed my suspicions. It’s called The Graph That Changed Me. Here’s an excerpt:

One day my manager showed me a horrible graph. It was pretty simple: the graph was steady, then it dropped straight down, then after a short period, the line shot straight back up and stayed level again:

Artist’s rendering of why you probably don’t like RealPlayer much
“That’s what happens when we do the right thing”, he said while pointing at the drop, “and that’s how much money we lose. We tried it just to see how bad it was for our bottom line. And this is what the data tells us.”

“Wow,” I said, taken aback. My employer clearly had two options: “do the right thing” or “be profitable”. That was the position they had maneuvered themselves into through a series of bad management decisions.

That “series of bad management decisions” may involve a slippery slope of subtle temptations and minor rationalizations, not one big bad decision to be evil. But having been there I know it’s all too easy to fall into the trap of binary thinking. You can hear it in that story:

two options: “do the right thing” or “be profitable”.

Design thinking is abductive, inventing new options to find new and better solutions to problems. In the universe of all possible businesses, were there more options than just “do the right thing” or “be profitable”? Of course. We just need to be willing to try harder, apply our creativity, and make “do the right thing and be profitable” two constraints of the design problem.

“We are going to make one computer for each quadrant”

Love this Steve Jobs story:

…Jobs turned around Apple and did it pretty quickly. He did two primary things as far as I can tell. First, he got his people into the top jobs and got rid of the executives who had been calling the shots before he showed up. And second, he brought focus to the product line, and thus everything else.

There’s this great scene in the book where Jobs draws a classic four quadrant chart, consumer and pro on one axis, desktop and laptop on the other. And he says “we are going to make one computer for each quadrant and we are going to kill all of the other product lines”.

Are Amazon’s Drones Crazy or Awesome?

Rosenfeld Media asked me my opinion of Amazon’s idea to use drones to deliver packages. Here’s a short excerpt from the interview:

Say what you will about Jeff Bezos, the man knows how to touch off a media storm. Which is precisely what ensued after Bezos told 60 Minutes that Amazon is testing the use of drones to deliver goods. Immediately, everyone was discussing the prospect of ordering a box of tissues from Amazon and having a drone arrive at your doorstep in half an hour. We’ve asked some Rosenfeld Media experts to join the fray on this audacious idea.

It’s a longshot that this will ever happen.  But let’s imagine for a moment that Amazon pulls this off.  A terrible road to go down, or awesome?

Victor Lombardi: The danger is in trying to answer this question using reason rather than experimentation. And that’s because drone package delivery is so new we have no idea if it’s awesome or not. To find out, we need to test it. The reason we fail to get these things right is because we fail to treat them as experiments. We fall in love with ideas, with visionaries, with progress for the sake of progress. And that leads to failure.

Read the the full interview at Rosenfeld Media.

My book, Why We Fail, is out!

This blog has been quiet for so long because I’ve been working on my first book, and it’s finally published. Why We Fail: Learning from Experience Design Failures is about websites and consumer electronics that were successfully launched and hailed as great designs, but failed unexpectedly when people used them, plus my attempt to explain why that happened and what people who make them can do to avoid failing.