Make Your Case – Why a Business Case is a Critical Component for Transforming an Idea into a Successful Product
Co-Founder, Berlin KraftWorks Inc.
There’s nothing more exciting than that aha moment – when the light bulb goes off for a great new product. It’s very tempting to dive in right away and start building. But it’s all too easy to get carried away creating, and forget to consider what a new product must do to be successful.
At the end of the day, a product is going to have to be sellable, someone is going to have to want to buy it. It will also have to make the company a profit and it cannot expose the company to any undue risks. That sounds simple enough, but there’s a lot there to consider and it can drastically affect how a product is designed and built.
That first inspiration needs to be weighed against a few very important business decisions to understand if the product is viable, and if so, what are the conditions it will have to meet to be successful. Initially, those decisions will likely be based around market size, time to market and a predicted sales price (potential profit). Those 3 basic criteria are already more than enough to shape the conceptual design.
Building a business case to define the expectations for a new product helps to direct the development and avoid costly unusable labour and purchases. It also lets everyone in the company understand what the goals are for the new concept. A new product that doesn’t meet the business goals is not going to be successful.
The new product idea may come from anyone in the company. It may be from sales filling a customer need, engineering implementing some new tech, or really anyone in the company. A good idea can come from anywhere, but it’s very likely that no one person will fully understand everything that goes into making a successful product. The more input you get from throughout your company will allow you to build a more comprehensive business case.
Typically, when you start to look at the new concept with respect to selling, the idea will change. External input may prove some ideas incorrect or point out missing features. Looking at the end sales volumes and pricing may dictate the eventual manufacturing methods and change the materials, interface, feature set etc. That doesn’t mean the idea wasn’t a good one to start with, it’s just going to help that idea be successful.
As the product ideas are developed, the business case will be refined as well. Like every other design document, it will be a living document. There will be more detail around use cases, regional differences, shipping, manufacturing, industrial design, etc. that affect the company goals for the product.
Take the time to build a business case for every new product idea. They don’t need to be complicated, start with the basics. With a business case in hand, you can begin to develop the new idea in a direction that has much a higher chance of success.
Co-Founder, Berlin KraftWorks Inc.
In part 2 of this series, I talked about the chaos of the very early stages of any company, or product and how to approach that chaos as both infinite complexity but also infinite opportunity.
Since its neither practical nor productive to try to create a product or supply chain system that is all things, to all customers, all at once, we’ve got to apply some boundaries to the complexity and opportunity. We need to focus – on the data, activities and risk/reward opportunities that will best bring us toward our goals. Preferably with the least amount of time, effort, and cost wasted as possible.
The planning hierarchy is the structure and the lens through which to achieve this. And, as a structure it allows you to apply a System Thinking approach to planning your product and your supply chain. The structure is applicable to any company that produces a physical product, regardless of if they are a start-up, or a well established multi-national giant. The key however, is in how to apply it. To understand that you have to have a relentless focus on your customer, and your business case to provide value to that customer as well as to the business (if the business cannot generate value, it won’t be a business for very long!) The hierarchy is the roadmap, how you decide to get there will determine your operations strategy and the overall success, profitability, and sustainability of your company. The further we go down the planning hierarchy, the more detailed and short term our decisions (and repercussions) become. But each level needs to be aligned to supporting the business case above all else.
A typical planning hierarchy (applicable to any manufacturing company) appears as follows:
Applying this framework to a start-up
In a start-up (as with any company) things need to be considered from two views simultaneously from day one: how will decisions impact the project/company today, and how decisions impact the project/company tomorrow and beyond. Building a brand-new supply chain from scratch is no different, since project or business decisions made today can have implications and costs that the company will have to bear for weeks, months or possibly for the entire product life-cycle including cost, risk, effort to produce, and agility to react quickly to changing market conditions.
For start-ups it can be difficult, if not impossible, to know all that you need to know for success. This is the complexity or chaos I’ve mentioned previously.
In order to overcome this, most start-ups will forgo any consideration of supply chain and focus on marketing and product engineering while leaving supply chain to a later date when there aren’t so many variables. In most cases, these firms will invest time and money into developing a product, only to have to do much or all of it a second time to produce a product that can actually be viable for manufacturing and supply chain, that will actually generate a profit, and will deliver measurable value to the customer. This time lag can be deadly to early-stage companies, who will either run out of funding or simply be beaten to market by a better organized competitor.
Instead, I argue that the planning hierarchy can be adopted to meet and overcome these complexities during development, not after. And the process will result in a purpose-designed supply chain that develops concurrently with the product.
Let’s walk though some ways to apply this.
Business Level Considerations (Annual Outlook/Consideration)
At the top of the planning hierarchy, your supply chain must consider the business case. The business case is the anchor. If this isn’t solid, anything tied to it will be no better. At the top of the planning hierarchy are the long-term and broad concerns to be responded to.
Long term considerations:
While nobody can expect to understand these elements fully (especially sales forecasts) for a new product or for an early-stage firm, it’s worth mentioning that they need to be understood as well as they can be and be constantly challenged when new information is available. The business case grows and matures in this way, and the complexity of the supporting planning hierarchy will grow and mature accordingly to support it. In the planning hierarchy, these are usually annual considerations since to change direction in any of these elements requires a major reworking of all supporting systems. It is also important to note that this is why supporting systems should be no more complex then necessary, for maximum agility in times of crisis.
Operations Considerations (Shorter term, typically monthly)
Once the business case is identified, vetted and validated, product development can begin in earnest. There may already be some napkin sketches or even conceptual models, but now all that must be tempered with the requirements of the business case. The development will look up to the business case and also any available feedback from potential customers or markets as a guide.
Inputs and outputs here can, and will, change more frequently than the business case, especially in product development because new information is learned as the development cycle progresses. In a production environment, this is a monthly exercise. But in a start-up, it should be considered at any decision affecting the product development and design.
A criticism I have often heard is “why spend that time for things that are only conceptual, isn’t that waste?” The answer is a firm no. All of this work, if documented, becomes your supply chain knowledge base specific to your product and it will inform both your design and your supply chain strategies as you go. It will orient your products and your operations towards viability at first, and competitive advantage over the long haul by steering you clear of pitfalls and avoidable challenges.
Detailed Production Considerations (Weekly)
In production, this level of detail is a weekly review cycle, but in a start-up, it becomes something completely different.
Start-ups that are just developing their products aren’t engaged in capacity planning or master scheduling of production. Instead, consideration needs to be given to how, at a detailed level, your product will be produced based on the development done to date.
Detailed production considerations:
Figuring these out post-development is far too late, and will force a re-do of much (or all) of the development cycle to re-align with the realities of supply and resources, before any real production can happen.
The opportunity here for a start-up, is to really research what resources are available and weigh cost against value. This is where you can build your database of who is out there, and what they can offer and share that with the development team. Its also a good opportunity to build relationships and vet ideas with potential manufacturing or supply partners who are subject matter experts. This is where the heart of your new supply chain – data guided by knowledge, will start to grow.
Daily Execution Considerations
At the bottom of the hierarchy is all the detailed day-to-day considerations of producing your product. In production, this would include daily activities around the shop floor – scheduling machines and people, daily material consumption and replenishment, as well as shipping and receiving (both your finished goods to customers, but also incoming supply of materials) to name just a few things. Ultimately, the details at this level will determine your profit margin, your quality, and your ability to satisfy the customer. In many ways the work done at higher levels will frame how effective work at this level can be.
For a start-up, this can be applied as additional detail to the elements already described when considering specific aspects of the design and how it will be produced in scale.
Considerations for daily operations:
Bringing it All Together
This is just the beginning. There is more that can be done to apply this hierarchy to a start-up, in order to streamline development and build a viable supply chain concurrently. Much more in fact than I can touch on in a short blog. But hopefully this illustrates how this framework can serve to cut through complexity and unlimited variability inherent in start-ups with a repeatable, scalable supply chain structure that can grow with the firm and guide the product development towards successful execution, by designing and developing with the end in mind the whole time. The effectiveness of the end result be governed by your supply chain, for better or worse. They key to remember is that it is never too early to start this process.
Electrical Design Specialist
There are many things a hardware design engineer needs to consider when embarking on a new project. When I started out back in the mid 90’s as an applications engineer, I did not have much design experience and I was lucky to be able to learn the ropes without the pressure of having to deliver a product at the end. I was designing hardware interface adapters and software applications to talk to cameras as well as FPGA code for CCD sensor timing to support customers. I have noticed that many of us today are spread so thin that there is little time for mentoring and supporting the more junior staff. Often, we leave the inexperienced on their own, letting them learn on the job. My hope is that this series of articles will give you a jump on your learning curve. Please note that I write this from the view of a hardware designer, though many of the points I will make are applicable to other specialties within Engineering.
You may be reluctant reading this. There is a good chance you consider the topic of requirements boring, as most design Engineers I know want to dive into their design work right away. For many of us that is why we became Engineers in the first place. After you have read this article, I hope you may reconsider and value the importance of your product requirements and use them as an inspiration to create great products. Spending time upfront has the potential to save you a lot of time and money in the months ahead. When complete, the requirements should provide you with all the information you need to know about what it is you are being asked to develop. The how will be explored afterwards.
Whether you are employed or you created a start-up, have you ever asked yourself why your company is doing what it is doing? What does your company believe in? Or is everyone only there to make money? Understanding and communicating the “why” will inspire your employees, your colleagues, your customers, and most importantly YOU. People will follow you and purchase your products because they are aligned with your beliefs. I always drew a lot of motivation and excitement from understanding why I was designing a particular product, how it was going to be used in the field, and how it would benefit customers and consumers. I found this especially important on days when things did not go so smoothly.
Tip: Check out this TED talk. I found it to be very insightful and in fact inspiring. It points out that to think about what, how, and why in that order does not inspire and lacks connection (my words). Instead the reverse order of why, how, and what is what gets people excited. Simon Sinek gives several examples, Apple being an obvious one.
Make sure you can and are standing behind the product you are about to start designing. I can only hope your company allows its employees to not participate in a product development, when it goes against some of your personal values and your beliefs. I had the situation once where I was asked to participate in a military smart gun development. I have never been comfortable around guns. Even as a young man living in Germany, I chose an alternate civil service when the time came for me to do my military service, which was compulsory at the time. So, I simply said thanks, but no thanks. Luckily my manager responded kindly and was totally understanding.
A bit more food for thought
I have been reading these articles written by my colleague, Les Hirst, and I thought I would mention them here. They may evoke a different side of product development, more in the direction of sustainability, longevity, and beauty. If you like to think outside the box, have a look at them.
A Side Note
You may wonder what these last paragraphs have to do with requirements and I would agree that in the traditional sense of that topic, maybe only a little. But the more I think about it, the more I believe that asking myself some difficult questions early on is essential for my ability to stand behind the product I am investing much time, sweat, and tears into.
Back to the topic at hand…
The image depicts the different points discussed below and how all of them influence the requirements. Each point is driven by stakeholders that determine and define your requirements.
The first thing I find useful is to understand who my stakeholders are. A stakeholder is anyone that influences your requirements and with it the product you are about to design. The list can become quite long and it can be helpful to divide your list of stakeholders into primary and secondary to better understand their influence.
Here some examples of stakeholders:
Understand how your product will be used – intended and unintended. You may be designing your product for a specific use, which is (are) your intended use scenario(s). It is a good idea to review this and investigate whether there are potential unintended uses. By doing this you may choose to expand your list of intended uses or you may need to discourage users from using your product in an unintended way.
We all use cell phones – the intended use was surely to get us more connected, to simplify life. One of the unintended consequences is how much time it consumes every day and how habitual its use becomes to us. Another beep, another light goes off and I am picking up that phone. How many times do I see a couple at a restaurant both staring at their phones? They are not talking and I jokingly wonder if they are texting each other… (I know it is a sad joke). Knowing the unintended consequences can be important to understand the impact a product may have on its customers.
What market is your product designed for? Is it a mining, medical, military, aerospace, or may be a consumer product? Depending on the market you may have additional requirements for design and manufacturing. You may also require ISO certified facilities.
The market often dictates what the customer is paying for the product. This has a direct impact on your Bill of Materials and the Cost of Goods Sold, which includes any costs to produce the product (excluding indirect costs). Manufacturing and indirect costs such as distribution and shipping may also influence where you are planning to manufacture the product and at what volumes.
Where in the world is your product being sold? Different parts of the world have different requirements for imports and thus influence product testing as well as environmental and safety certifications. This will have an impact on your ability to sell and ship to these countries.
For the purpose of shipping, your design may also be influenced by requirements such as weight, shape, and size of the product and its packaging. In order to manage these aspects, the product may require partial assembly by the customer.
Environmental and Safety
Think early on about how safe your product is for users and the previously discussed intended and unintended use cases.
Mechanical and Industrial
Your product likely requires some sort of housing. No matter how simple or complex this housing is, all functional inputs and outputs (such as buttons, switches, displays, LEDs…) need to be specified to ensure your design can support it. If possible, understand what type of industrial design the marketing and product management folks are thinking about. You will also want to understand how humans or machines interact with your functional inputs and outputs.
Tip: In many cases the shape of your PCB and the location of components is driven by the mechanical and industrial design aspects of the product, not where it is necessarily convenient for your circuits.
Mechanical designers have their own set of requirements, often related to the materials they need to use, tolerancing the design for (mass) production, and so on. Your PCBA in essence becomes a mechanical component in your product once assembled.
Tip: Today’s tools are great in creating visual 3D models of the PCBA and letting the mechanical designers import them into their work. This minimizes risks for interference and assembly.
As a design engineer you are likely familiar with gathering and/or receiving any functional and performance requirements for the product you are to design. Make sure you understand how the product is supposed to function and as mentioned above how others interface to or with it. Also have a good understanding on how the product is required to perform and why.
I suggest you take time and study these requirements. Clarify any questions you may have and ensure that nothing is left up to chance. The better your requirements, the easier it becomes to design the product. If at any time in the design phase questions arise, ensure to get clear answers from your stakeholders and don’t forget to amend the requirements.
Tip: Spend time on checking and rechecking the requirements to see if anything was missed.
Failure Mode Effect Analysis (FMEA)
Make a decision early on whether you want apply an FMEA to your product design. It provides the opportunity to mitigate design risks early on, and lowers overall costs of development and production. Design FMEA (DFMEA) explores the possibility of product malfunctions, reduced product life, safety, and regulatory concerns.
If you choose not to do a DFMEA, consider identifying these types of risks in your product design informally and find ways to mitigate them early on. Think about and investigate what might go wrong. If, for instance, a customer can apply the wrong product input voltage and has the potential of creating a fire hazard, you may need to include in your requirements ways preventing that.
Note: Writing this I remember the 2016 Samsung Galaxy Note 7 cell phone recall, because the batteries could generate excessive heat causing fires and explosions. Not good…
Manufacturing and Supply Chain Management
Check with manufacturing, purchasing, suppliers, component engineering, … if they have any specific requirements for your design. Chances are they may want to provide you with information on what components or suppliers to avoid or where you might encounter prior known risks.
Tip: Many Contract Manufacturers (CMs) have readily available documentation outlining many of their design requirements.
Many design aspects require considerations that are best studied and discussed early on in product development, thus can and should be included in the product requirements. Leaving these discussions and the collection of information to a later date will have an impact on your architecture and your design as well as your ability to deliver product to market on time.
This article was originally published on HaraldSiefkan.com and has been reposted here with permission.