You might have heard about Adobe diving into the hardware scene this week with two new product explorations.

Mighty is a cloud-connected, pressure-senstive stylus, and Napoleon is a digital ruler and template tool bringing the efficiency of old-school drafting tools to tablets. Both address the fact that after decades of digital design tool evolution, designers still ditch them in favor of pen and paper for an important part of their creative workflows—sketching and natural drawing.

Mindtribe led development of both Mighty and Napoleon.

Mighty and Napoleon, Adobe’s Drawing Hardware Developed by Mindtribe

Mighty 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.

Napoleon hearkens back to the drafting table era by allowing you to quickly draw straight lines and basic shapes, a là your T-square and circle template. Deceptively simple, this is one of those things that 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 create a product to solve a user problem in a new way, you probably don’t think of a large company.

Furthermore, Mighty 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, Mighty is an exploration based in hard reality.

How’d Adobe Do It?

Easy: don’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 in any case is usually more hit-or-miss proposition than sure bet.

To help Adobe overcome the challenge of building hardware 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. Nearly continual user testing from the earliest stage of development closed the loop 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 “here, go build this,” 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 a wrench 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 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 of product focus 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.

With a prioritized list of user needs, feature discipline to include only those that meet those needs, and stakeholders aligned on those, any feature ideas that weren’t required to address the most important user needs were 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, Mighty and Napoleon have been successful hardware explorations—innovative hardware from a software company.