Defining A Product

Why specifications and definition expedite the development process

You know what your product is, right? You’ve been building it up from scratch, it’s your baby, you have been working on it, concepting it, and convincing your friends and family it’s a great idea. You understand the customer pain point, better than most because you’re willing to put in the time and effort to address it. Now’s the time for you to bring in the experts, the engineers and designers to help make your product a reality. They sit you down and ask you for a list of specifications and product definitions. But isn’t that why you’ve brought them on board in the first place? They’re the experts who you want to help you flesh out these details. For example, you don’t know what the exact milliamp hour capacity of the battery is, or what material the 3D printed gasket needs to be made out of to ensure your IP67 rating. What are the engineering and design consultants looking for?

I once had a veteran entrepreneur tell me the most skipped step in product development, especially when working with engineers, is understanding two key parts of your product:

1. Does the market actually WANT your product the way you’ve outlined it?
2. How do users interact with your product?

It is common to see young companies struggle with these two points. They think they understand what the market needs, but after months of talking with their potential customers do they really understand what the customer wants and how their product can fit the pain point. By this time, a substantial engineering effort has been performed bringing the design closer to the wrong goal. BES often tells potential clients to go talk with their potential customers. Understand how they can address user needs - not what they THINK needs are. It’s not uncommon to spend hundreds of hours pounding pavement to make sure you’re going to be building something people are going to WANT.

Once you understand what your customers want, the next biggest challenge is to understand how to translate that into functional, achievable product specifications and definition. Most people understand what this entails at a high level. It covers what your product looks like, what functional requirements it needs to meet, how long the battery lasts, etc. The problem comes when you dive down into the nitty gritty details of the product. What do you mean when you say something is going to be “light-weight”. That could mean 10 oz for one product and 5lbs for another. What happens when your user leaves the device plugged in for 10 days straight? What does the product do when it’s out of cellular range? What happens if a user is trying to update it and it shuts down? As a product owner, you not only need to define your product on a physical and electromechanical layer, but you also need to define it on a user interaction level.

Thinking through all potential ways a user can interact with - and break - your product will allow you to ensure every possible touch point you get with your user is handled elegantly. It will also allow you to think through the flaws and minute details of your product that you hadn’t before. When you approach a design house these are all things they should be thinking about the second they start to dive into your product. If they aren’t, run. If you approach them with a well fleshed out set of user stories, product definition, and well researched and defensible specifications, you will save schedule time and associated product definition costs. They will be able to flesh out contradictions and compromises you may have to make in your product - size and battery life are common examples early in the development process. This can prevent your designer from making misguided assumptions about what you want, or worse not considering the long-term implications of their design decisions because they assume it doesn’t matter to you.

At BES, we often see clients with varying needs for defining their product. We will gladly collaborate on these efforts in order to achieve comprehensive product definition documentation. This is often an iterative process and can add up to be a substantial undertaking. However, this effort typically pays dividends later in the project, often reducing the likelihood of a scope change that results in increased schedule time or budget. Whether a client needs guidance from our team throughout the process, or if a set of well-defined specifications and product requirements has been created, we can support these efforts to reach the desired outcome. After all, you know much better what you’re looking for out of your product than we ever will. We find this is often the least ambiguous path for our team and provides us the ability to pinpoint problem areas as early in the development process as possible. There is no “one size fits all” for product definition and each one will look different depending on the product and the target user.

Interested in learning more about Boulder Engineering Studio? Let's chat!

Previous Blog Posts

Design and the Environment	Switched On: MOSFET Selection Guide