Inside Apple And IBM's App Making Machine

Apple helps IBM design enterprise apps by starting projects with a three-day workshop in which they work out the key aspects of the app.

When IBM gets an order for an app such as Passenger+ from one of its enterprise clients, it invites key members of the client’s team in for a three-day workshop at Apple’s Cupertino campus. At the beginning of Passenger+ development, Air Canada sent IT people, managers, and flight attendants to the workshop to hash out the basics.

This is similar to the process we use at Appiphony. Though there isn’t time to sort out every tiny detail in a few days, the group has reached consensus on the core elements of what the app will do and how it will work.

Note the emphasis on talking to the actual end users of the app.

In addition, Apple requires that end users from the client—such as flight attendants in the case of Passenger+—are there to provide their unique view of what they need from an app. The company believes that this step is essential for prompting an immediate “Oh I know how to use that” reaction from the people who will actually use an app, one app designer told me. It also cuts way down on the training time needed to initiate new users.

Miller-Sylvia told me that this insistence from Apple doesn’t always play well. “You can’t imagine how much push-back we get from the client, because the managers think they know,” she says. But “all of the transformation comes from the end users being involved. There’s so many things that they do, and the managers end up getting surprised in the sessions and saying, ‘We had no idea.’”

During one workshop, one of the end users explained: “When I need to do that, I just write it on my hand,” Sylvia-Miller recalls. “And the manager was like, ‘you what?!’” It’s exactly this kind of nitty-gritty day-to-day work reality that gets exposed during the three-day workshops—things a middle manager might never know about.

It’s odd how this is seen as problematic given that it costs so little in time and money, and almost every company talks with customers after products are delivered to gauge customer satisfaction, Net Promoter Scores, etc.

How to Write Great “Elevator Pitch” Release Notes Like Amazon kicks off new product initiatives by writing a hypothetical press release announcing the arrival of the product, then iterating on that message until the vision is sufficiently compelling. It’s a fantastic technique, but it results in a few hundred words. Their release notes, however, provide an example of how to distill that message into a (much shorter) elevator pitch.

Here’s a recent update to the Kindle app:

First, they introduce the new feature—branding it, if you will. Then, they call out the benefit the feature creates. Finally, they list the actual feature(s) and provide some details on what it does.

The subtle, but critical ingredient here is highlighting the benefit users will get. If you scroll though your app updates, you’ll see that’s few and far between. Most vendors just list the features, like the one that happened to follow Amazon here:

A prior update to the Kindle app followed Amazon’s pattern:

The branding is not as strong, but we still see the benefit—even though improvements to typesetting and visual design can be tough to capture in words.

Instapaper had a theme for a recent release, which gave them an easy way to explain why a certain set of features arrived together. Without that, a update can feel like a grab bag with no clear “hook” for customers to understand it holistically.

FiftyThree did something similar when releasing a new module for their Paper app. They introduce/brand it, give a quick overview, and then touch on each tentpole feature and the benefit it provides. In their case, that translates to an easier way to accomplish what was tedious in the past.

Adding the “Who”

If you’re building technology for the enterprise, you’ll probably need to include the target user(s) served by the new feature, for example:

System administrators can protect corporate data if a mobile device is lost or stolen with the remote wipe capability introduced with iOS 4.

Once you add that element, you have something that lines up nicely with the Customer-Problem-Solution framework from Lean Startup. If you’re already using that approach, you’ll have a great starting point for this exercise.

Whatever you do, begin with the end in mind so you have more than a list of features when it’s time to ship. Remember: code is a liability. The benefit it creates is the asset.

Don’t Stare at the Scoreboard


Analyzing the final product: staring at the scoreboard

Let’s say you’re building a product, and you do some competitive analysis to see how others have addressed the same problem. Sounds reasonable, right?

Here’s the trouble: if you can only look at the final product, and can’t see any of the work that led up to it, you’re missing most of what’s interesting. What trade-offs did the team make based on what they learned along the way? What’s planned for the next release? How did they arrive at their design decisions?

It’s like staring at the scoreboard of a baseball game after it’s over. If you didn’t watch the game, you won’t get much out of it. You missed all the action.

Photos courtesy of Eric Kilby and Keith Allison

The Product Thesis

A concise, easy way to communicate customer needs to design and engineering teams to build the right things.

Answer these questions for the team building your product:

  1. Why are we working on this next?

  2. In what scenario is this used?

  3. What problems do we need to solve?

  4. What future considerations must be accounted for?

  5. How will we know this is a success?

I’ve been thinking about what it means to document and communicate a product at a medium level of grain—between 10,000 feet and the weeds. This helps in that regard.

Teaching Design to Engineers

Designer and Lean UX pioneer Lane Halley posed this question on Twitter:

What do you think? How much UX can and should a “full stack developer” know?…@carbonfive

— lane halley (@thinknow) June 7, 2013

The article linked in the tweet states that the true “full stack” developer should have knowledge starting down near the metal, stretching up past the UI, into the user experience and beyond, into the business. (I’m exhausted just thinking about it.)

I fear the person asking this question will not get the outcome they want. Knowledge by itself can’t be a bad thing, though in my experience motivation is the real source of magic. I have some strong opinions on this, because I’ve been fortunate enough to see the results when engineers become excited by shipping products others will value, instead of solving puzzles for their own enjoyment.

The engineer mind

Solving puzzles is where it all starts. When today’s programmers were children, they enjoyed building with Legos, working hard until the pieces fit together. Tomorrow’s programmers are ignoring their meals and debugging their Arduinos as I type this. Why? Because it’s fun! At least, they think so.

Actually, let me rephrase that: It’s fun for them. They extract enjoyment and learning from it, and those positive outcomes go into their hearts and minds. Even if they’re just passing the time, the critical distinction is the activity is about them and not another person.

Can you hear me now?

Here’s another example: the recently released book Exploding the Phone: The Untold Story of the Teenagers and Outlaws who Hacked Ma Bell tells the story of the teens and twentysomethings who figured out how to “hack” the phone system and make free long-distance phone calls in the 1950s-1970s. The author stops to make the point that these kids had no one to call. The goal was not to save money or stick it to The Man; they just wanted a challenge.

Here’s one anecdote from the book: the pranksters called several military facilities and were busted by the FBI. Since this was the Cold War era, the authorities thought they uncovered a ring of spies. The interrogation was intense, and only ended when an AT&T engineer produced records proving the kids had made no calls of any possible value. The G-Men couldn’t wrap their heads around the fact that the kids would spend so much time reverse engineering the system without a “real reason.”

But, to them, they had a reason: it was fun. And they learned something.

The big shift

Product teams need to take talented people like this and get them to build something that someone else will use and like, whether or not it’s an exciting technical challenge. By hook or by crook, their focus needs to move outward into the messy world of people and their problems. And, since comparatively few organizations are truly design-led, it’s incumbent upon designers and product managers to build bridges to these awesome folks and activate their amazing potential.

The good news is, it’s possible. I’ve seen it happen; it’s incredible. In our case, a key front-end engineer attended a design conference, and our seating chart worked out such that he sat back-to-back with our (also incredible) visual designer. Before long, the two of them were working on ideas of their own, and we were shipping stuff that was both well-designed and well-built.

That success inspired me put together a UX “crash course” targeted towards developers. If you have a roomful of developers, I’d love to share that message again. I truly believe the single most effective way to improve your organization’s products is by getting the engineers to care about design.


If design isn’t a big part of your company’s culture, don’t worry about how much engineers know about design and user experience. Building things for others isn’t why they started their career. Get them to care about shipping things others think are great, and backfill the knowledge they need a little at a time. They have to want the knowledge before you hand it to them.

Questions are places in your mind where answers fit. If you haven’t asked the question, the answer has nowhere to go.

— Clayton Christensen (@claychristensen) August 3, 2012