7 Key Steps to Building a New Product

7 Key Steps to Building a New Product

Categorized under: technology development

Since graduating from the University of Illinois Urbana-Champaign 20 years ago, I have been in the fortune position to build a series of technology based products and services. As part of my career, I thought it would be helpful to outline what goes into building the many different inventions and innovations that you often engage with on a daily basis.

At Digital Adventures, our goal is to demystify the process of learning to code and build with technology for the next generation. One key element of that is learning the process for how new products and services come to life.

1. Figuring out what you want to build

One of the most important steps in the entire process is figuring out what you want to build. At Redbox, our goal was to come up with a way to automate the consumer sampling process within retail environments. There are many different strategies that we could have employed. However, what we ultimately decided is that an automated kiosk would best meet the needs of our customers, brands, and retail partners.

At a high level, an automated kiosk is far too generic. We need to get more specific in what exactly that means in order for us to build something that customers, retailers and brands would find value in. To do that, we need to define the requirements of the product and memorialize that information into a product requirements document.

2. Define the requirements of the products

Since our automated kiosk would live within the retail environment, specifically the beauty section we need that space would be limited. We also knew that we wanted to have an outward aesthetic that would make our kiosk look attractive within the areas of the store that we were being placed.

In addition, since we expected our kiosks to be utilized frequently, we needed to have a way to offset any potential lost revenue the retailers would earn from slotting fees when our kiosk displaced inventory on the shelves.

3. Developing a product requirements documents

Once we have a clear definition of our boundary conditions, we needed to create a very specific document that outlined these requirements. We got very specific on power consumption, system architecture, kiosk material, high definition screen size, onboard computer processors, system memory requirements, security and payment methods.

When building, there is always a tradeoff between what is intended and that which can actually be done. For example, we didn’t want our products to have a hard thud when dispensing. So, we designed a clever way to grab products and present them to the customer that was specifically not like a vending machine.

This requirement meant that there would be less space for inventory within the kiosk. However, we decided that because the user experience of having a sample presented in a gift bag without the typical drop in other applications was worth the compromise.

4. Development team building & get feedback

With a product requirements document in hand, the engineering & design team could begin building the initial prototype. During this process, there is a necessary period of translation and interpretation. For some hard requirements like kiosk inventory, it is easy to know whether or not the metric has been met. For other requirements like beauty aesthetic or intuitive user interface, different engineers and teams can reasonably disagree.

In fact, there is a constant challenge when building a product between what is visually appealing and what is technically possible under a set of time constraints. Technical teams that are able to embrace the mindset of a design team and design teams that are able to appreciate the technical challenges are those that end up making amazing products that consumers just love.

Those who place their team requirements above one another or often the ones that struggle to get traction. During the initial design reviews is when team preferences and openness to respect for the other disciplines becomes very apparent.

5. Iterating on the initial requirements to refine the look/feel/function

Once a product has been designed, there is usually a period of time where the initial versions are shared with the internal team or a focus group of prospective customers. During these reviews, the goal is to see how the design intent matches user behavior.

For our automated kiosk, we design an intro video that would cycle through different visual images. We wanted to see if that would capture the attention of prospective customers within the busy retail environment.

We found that not only did it generate the necessary curiosity, they also were more likely to bring others over to the kiosk to see what it was all about. However, there were other elements that we found did not meet initial intent. For example, we found that customers required the ability to pay with cash.

Even though most kiosk systems had been moving towards credit, most customers told us that they felt it was nice to treat themselves with the few dollars they had in their purse without their partners knowing that they had made a purchase. This requirements us to revisit our initial assumptions and make key tradeoffs to integrate both a cash and credit payment option into our kiosk design.

6. Product launch // customer feedback

After a period of multiple reviews, a product is usually ready for initial consumer launch. Prior to this period assumptions have been typically tested on a smaller scale. During the product launch, the goal is to get the new product or service in front of a larger group of customers to expand the use cases and to gather data for use in further refining the offering.

Prior to this, the team would have worked to develop a comprehensive go to market strategy to make sure that enough potential users were aware of the product or service. Often times, this is when new product or services are switched out of the development environment and into the production environment.

Often times, this initial repeated exposure by actual customers uncovers a multitude of issues that the team did not previously consider. This usually requires rapid fixes to make sure that issues do not turn into negative customer experiences.

Teams will often spend lots of time analyzing customer data during this time period to see what features and functionality is most beneficial. This helps reinforce the value proposition and see what bugs should be prioritized for subsequent development cycles.

7. Iterating on the launched product to refine the look/feel/function

After a sufficient period post launch, it is often helpful to begin to iterate the product to better match what you intended to build and what customers are desiring. Typically, this work is segmented between bugs and refinement of core product features.

For example, with our automated kiosk, we found that it was taking too much time to make a product selection because our user interface required too many clicks to choose a sample. So, we re-configured our user interface to make it so that we had a few featured products that customers could jump right into and allowed a more measured path for other selections.

Another issue that we needed to address is that we wanted to have the ability highlight samples with promotional codes. This would allow us to make a special offer to our customers during Mother’s Day or Valentine’s Day. To accomplish this functionality would require our development team to build a 3rd payment type: promo code. While this required a tradeoff with other key features on the product roadmap, it helped us cross promote our automated kiosk through Redbox’s massive consumer email platform which helped grow our user base tremendously.


While the above is a high-level, simplified version of what it takes to build a new product, the hope is that this information is helpful. It is often very challenging to bring a new product or service to market. For those who are able to do this and gain traction with their new innovations or inventions, it can be some of the most satisfying work of your career. Our goal is that members of the next generation would get excited about this process and begin the education necessary to developing solutions to some of the most challenging problems that are out there. Onwards and upwards!

About the Author: Omowale Casselle is the Co-Founder & CEO of Digital Adventures.