How To Create A Kick-Ass Product

This is the first article in a series about how to create kick-ass software products. From start to finish, involving business, design, and engineering components. This is most useful for entrepreneurs, since most of the advice assumes you’re building a product from scratch, and with limited resources.

What do I mean by a “kick-ass” product? It’s a product that takes minimal resources to build while satisfying your user and business needs. Alright, let’s talk about how to make a product as awesome as a rainbow unicorn magic cupcake.

Use an Inter-disciplinary process

In today’s world, the challenge is to bring software to market as fast as possible. I observed this need over and over again when I founded the software firm Konsult. Konsult targeted early-stage startups, so being efficient with time and resources is especially important to us.

Inefficiencies of existing software processes

Traditional product development cycles are siloed and inefficient. In the waterfall approach, the designs for the entire product had to be complete before it’s given to engineering, then released to users. This resulted in slow product cycles (on the order of years), and any user feedback could not be addressed until the next product release.

Recently, agile development and Scrum took over as a faster approach. In Scrum, designers and engineers focus a subset of features at a time, creating short cycles called sprints (on the order of weeks). Testing between the sprints allow them to address user feedback before the product is even released. However, due to the tight delineation between sprints, designers have to do all their work in the first sprint, then throw it over the wall for engineers to implement in the next sprint. This siloed approach misses many opportunities for the teams to collaborate and share in their expertise, and thus misses out on innovation and optimization.

The inter-disciplinary process

At Konsult, we needed to be efficient without compromising quality. Many of our startup clients use what we’ve built to pitch to investors. We’re always on a tight deadline, the budget is always limited, and the product always needs to impress.

We’ve developed a process allows designers and engineers to work concurrently and prevent inefficient decisions.

My process for creating a product

The most notable feature in our approach is that every discipline — business, design, and engineering — is involved at almost every stage of the process. It may seem counter-intuitive to involve more people when you’re trying to move fast, but it works because:

• It prevents us from making decisions earlier in the process that makes things harder later in the process.
• It allows us to pool the experience of every discipline, giving us more information to make decisions on
• It allows the downstream disciplines to start producing what they can with partial decisions from the upstream disciplines.

For example, when I was an engineering lead consulting at Bazaarvoice, we cut a feature’s development time by half due to the involvement of the product manager, designers, and engineers in defining the MVP. More specifically, the original MVP featured submitting reviews via a web form and via email reply, and we were able to decide that a web form was unnecessary because:

1. My engineer and I knew that the web form and email reply offer the same function but would share no code, and therefore it’s more efficient to focus on one for the MVP.
2. The product manager knew that email reply can generate more buzz due to its novelty, but was worried that not having a traditional web form would confuse customers.
3. The designers knew that since these reviews were invite-only by email, it would not be confusing if the response action was only available through email too.

The involvement of every team allowed us to halve the product development time by cutting the web form feature.

Without the engineers, we would not have known there is a redundancy we can remove. Without the product manager, we would not know which option is better for business. And without the designers, we would not know that it’s safe to remove the less desired option. Removing an unneccessary feature and reducing production time was only possible when these three disciplines were all in the conversation.

Another example of increased efficiency through inter-disciplinary collaboration happened when I was the consulting designer at Xoo. I worked directly with the engineer to create a bouncing scroll animation on the home screen of Watcha Doin’?

The pink half-circle stretches and bounces as the user scrolls. Try it yourself, download Watcha Doin’? from the App Store.

The traditional approach involved the designer creating and tweaking the animation in After Effects, then having the engineer code the animation “for real” using a library that may or may not have the same “levers” as After Effects. This is extremely inefficient. So, to move fast, I gave the engineer mockups of the key frames, a verbal description of the motion, and existing videos of a similar motion that I found online, all of which took very little time. Then, when the engineer had implemented it, we sat together to tweak it in real code, so that what I approved is exactly what the user gets. I learned this approach from when I was at Apple, where the designer would roughly describe the concept, the engineers would create the animation, then the two would tweak it side-by-side until it’s perfect.

The inter-disciplinary process is inclusive, which means that downstream teams, such as engineers, are informed of and can prepare for upstream decisions, such as feature functionality. When my company Konsult was building an app called Yo! (not the famous one) for a client, we’ve decided on timed chats as an MVP feature. Once we created the basic workflow — a chat would move from the “current” list to the “past” list once the timer is done — our engineers could start building the timer functionality without knowing what it looks like in the design. This allowed us to design and build the app in parallel, allowing us to define, design, and build the iPhone chat app in just a month.

Yo! — a photo and time based chat app

Throughout my time at Apple and Konsult, I’ve used part or all of this interdisciplinary process to create products for starts and large corporations alike. We would adapt the process to the constraints of our clients: skipping user tests for urgent projects, or omitting animations for B2B software in favor of more powerful features. However, we never forgo involving multiple disciplines at each stage, so we have the most complete and accurate picture of our priorities at all times.

The rest of this series focuses on the individual stages of the process that are often misunderstood or easily forgotten, but are extremely important to creating a lean yet powerful product. They also have more pretty pictures!

Part 2: Cull your MVP ruthlessly

Part 3: User studies are cheap and easy

Part 4: Great UX balances emotion, efficiency, power, and simplicity

Part 5: Tips for shipping extremely cheap & fast