Big Ideas

Innovative Hardware from a Software Company: How’d Adobe Do It?

In 2014, Adobe emerged, unexpectedly, onto the hardware scene with two product explorations: Ink, a cloud-connected, pressure-sensitive stylus, and Slide a digital ruler and template tool bringing the efficiency of old-school drafting tools to tablets. Both products address the fact that after decades of digital design tool evolution, designers still ditch them in favor of pen and paper for important parts of their creative workflows—sketching and natural drawing.

Mindtribe led development of both Ink and Slide. Ink simulates a pen-and-paper drawing experience on the iPad as a high performance, pressure sensitive stylus. It’s also cloud-connected, to enable copy-and-paste across devices (say, from your tablet to someone else’s phone), and instantly pull down your personal content and preferences from the Creative Cloud to wherever you are. Slide hearkens back to the drafting table era by allowing you to quickly draw straight lines and basic shapes, à la your T-square and circle template. This is one of those things that is deceptively simple, and has to be experienced to be appreciated.

Innovative Hardware, From a Software Company

When you think of innovative hardware, you probably don’t think of software companies. When you think of being first-to-market with a product that solves a user problem in a new way, you probably don’t think of a large company.

Furthermore, Ink isn’t a hacked-together prototype: from the metal body, which is the smallest and thinnest-walled structure hydroforming vendors have ever undertaken; to the smallest “rubber nib”-style tip of any active stylus available; to the pressure sensitivity mechanism users have said is better than any other product on the market, Ink is an exploration based in hard reality.

How’d Adobe Do It?

They didn’t develop hardware the way most hardware is developed.

With Mindtribe leading the product development effort, Ammunition leading design, and the Adobe Ideas team writing software, we set out to turn a vision from Michael Gough and Geoff Dowd at Adobe into a product that designers have wanted for 25 years.

What did we do differently?

Developing technology products can be a painful experience for hardware companies, let alone software companies, and making products people want is usually a more hit-or-miss proposition than sure thing.

To help Adobe overcome the challenge of building a hardware product people want, from within a software company, Mindtribe structured the development around avoiding as many classic hardware development pitfalls as possible. Here are a few:

  • Don’t assume you’re building the perfect thing.

A product vision is often handed to engineering and they’re told “here, go make this.” This is how the majority of hardware is developed, and there are numerous problems with it.

The biggest is that the team blindly builds the product in a vacuum, assuming they’re building the perfect thing, rather than seeking and responding to new learnings throughout the course of development.

We actively sought all the new inputs we could—user reactions, Adobe’s business needs, technology limitations, and so forth—and incorporated them, on a weekly basis, using agile software development techniques throughout the entire development effort. We instituted continual user testing from the earliest stage of development to help us validate and tweak our vision of what people wanted. Furthermore, a list of prioritized user needs enabled testing of the most important features first, very early in development.

  • Don’t mistake a product vision with sufficient product definition.

Every great product starts with a vision. It has to—users are notoriously bad at telling you what they want. But when a product development team is handed a product vision, and told to build it, that vision is nearly always less complete than it’s assumed to be. The product is typically only defined to the point that people feel comfortable internalizing what it is in their minds. In reality this is a very coarse level of definition, and on day one of development, questions about features and implementation details start popping up and slowing the team down.

The majority of these details are typically resolved arbitrarily by an engineer, a designer, or the original vision holder, and they’re resolved inconsistently (and slowly) since everyone has a slightly different interpretation of the product vision. Furthermore, stakeholders naturally prioritize and interpret aspects of the product vision differently based on their roles and what they care most about.

At the inception of development, we did an exercise with all stakeholders (anyone who could potentially throw their opinion into development later on) to call out the exact user needs the product would be addressing, in order of importance. We effectively transformed the product vision into a prioritized list of user needs, and after plenty of spirited discussion, all the stakeholders agreed on that list. Then the product definition became the minimum set of features required to meet those needs. (We also had to ensure Adobe’s business interests were met, but we only did this by tweaking the user needs we chose to address—everything still had to be 100% addressing actual user needs).

  • Don’t build something because it’s cool.

The kiss of death for a product definition is when a feature is added because “it’d be cool!”

Of course everyone wants to build a cool product. Unfortunately there are many more things that are cool than people actually want. Whether it be a single feature or an entire product, it’s cool isn’t good enough for users.

Start with a prioritized list of user needs. Have discipline to include only those features that meet those needs. Then get stakeholders aligned on features. Any feature ideas that aren’t required to address the most important user needs should be quickly shot down.

  • Don’t work on whatever seems best.

That’s right—don’t work on what seems best. As is the case for most of us, engineers tend to work on things in the order of what’s most worrisome, the most familiar, the most fun, or simply what seems most important. Those priorities are not always what’s actually most important for the project.

Borrowing from agile software development techniques, everyone on the team would plan their work a week at a time, based on the highest priorities as established by engineering, business, and customer voices at our weekly planning meeting.

  • Don’t limit engineering-business interactions only to bombshells.

Once product development gets off the ground, engineering and business teams typically stay as far away from each other as possible. Neither knows how to engage with the other, so interactions are limited to bombshells like a changing cost target for a product, or an engineering delay that’ll cause a significant delay of product launch.

How can an engineering team possibly build the best product without knowing the latest business constraints? How can marketing make a feature request if they don’t know the schedule hit?

Having both engineering and business voices present when planning work each week, trade-offs can be talked through and a shared set of priorities established.

Based on user feedback, Ink and Slide have been successful hardware explorations and demonstrate the ability of software companies to create innovative hardware.

Here are Ink and Slide in action: