Why a Use-Case Analysis should be your first step in identifying your product requirements
August 30, 2022

When considering product requirements, startup founders and investors will often consider the questions: 

What features are essential, 

what features are nice to have, 

and what features are distractions? 


You may have a good idea with a clear customer value, but if you implement the wrong features, your product could still flop. Understanding the Use-Cases in which your product will be used is the essential precursor to answering these formative questions above. 


Use-Case Analyses are effective at identifying product requirements because they let you step into your customer's shoes. They allow you to experience the frustrations of your product firsthand before you even start designing it. 


Doing a Use-Case Analysis early in product development will help you: 

  • Develop a comprehensive product requirements list that considers your customer's needs 
  • Focus your engineering talent on features/problems that matter 
  • Go to market sooner by reducing late-stage redesign 

What is a Use-Case Analysis?

A Use-Case Analysis is a three-part activity. 


First, you identify how a user interacts with your future product or existing products on the market. These user interactions are called Use-Cases. 


Second, you analyze the Use-Cases for complexity. 

E.g., Are there any unnecessarily tricky steps? Are there too many steps? Or does the user have to make difficult or unnecessary decisions? 


Lastly, you eliminate the complexity from your Use-Cases wherever possible and important. 


Eliminating complexity will improve your customer experience by saving them time and headaches; and helping them avoid use errors. 


Always consider the three main aspects of Human Factor Design: the Users, the User Interface, and the Use Environments, when determining the importance of removing a step/decision.


 What are some successful Products that have employed a Use-Case Analysis? 

The products in the examples below have distinguished themselves by removing steps or decisions customers would otherwise have made. 


They were successful in removing the right steps because they considered the three main aspects of Human Factors Design: 

  • the Users, 
  • the User Interface, 
  • and the Use Environments.

1. Gmail Smart Compose

In 2018, Gmail launched a new feature so Users can write emails faster. 


Gmail now performs the first step of entering a recipient's name (e.g., "Hi Jacqueline") and will also propose phrases matching your typical structure and tone. 


While typing “Hi Jacqueline” takes seconds, this feature saves Gmail users more than a few simple keystrokes. It allows users to jump quickly into the meat of their email—no more moments of hesitation or pleasantry considerations. 

Image: Google

This example shows the importance of considering the User when doing a Use-Case Analysis. In this example, the critical User characteristic is their mental state of being in a hurry. This mental state may feel like a universal User condition, but depending on your product, it may differ. If Google were making software for writing personal journal entries for self-reflection, this feature would likely be more annoying than helpful. In that scenario, the User’s mental state would be very different. 


By considering the Use-Case and the User, Google honed its Machine Learning tech on a problem that matters to its Users: writing emails quickly. 

2. Breville "A Bit More" Toaster

In 2017, Breville unveiled a toaster with a new feature, the "A Bit More" button.

Image: Breville

The button aimed to fix the problem that we all know too well: 

  • You put bread in the toaster. 
  • It comes up too light. 
  • You put your toast back down, intending to stop the toaster shortly. 
  • You forget. 
  • Your toast is burnt. 


Breville solved the Burnt Toast problem by analyzing this Use-Case and considering their User Interface's limitations. They added an "A Bit More" button to remove the impact of User forgetfulness. This User-Interface addition changed the Use-Case to: 

  • You put bread in the toaster. 
  • It comes up too light. 
  • You press the "A Bit More" button. 
  • Your toast is perfectly cooked. 


Breville's solution to an age-old problem did not require significant technological advancements or a genius designer. All it needed was a comprehensive Use-Case Analysis with particular attention to the User Interface to identify the problem that needed solving. Once we know the problem, fixing it is rarely all that difficult. Sometimes it is as simple as adding a button. 


Once we know the problem,

fixing it is rarely all that difficult.

Sometimes it is as simple as adding a button.


P.S. The Atlantic thought this product was worth a full write-up: Why a Toaster Is a Design Triumph


3. Japanese Ketchup & Mustard packet

Japan, the country that brought us The Toyota Way, brings another leap forward: single-hand operated Ketchup and Mustard packets. 


You may be familiar with the problem; you have a hotdog in one hand and your sealed ketchup and mustard packets in the other. How do you open the packets?

 

Some use their teeth; others try to use a few fingers from their hotdog hand; others search for a clean resting spot for their hotdog. 


Each option presents risks, whether to the hotdog or our clothing. 


7-11s in Japan have dealt with this problem by creating a ketchup and mustard packet that can be opened and dispensed with one hand. 

Image: Imgur

This example shows the importance of considering the Use Environment alongside the Use-Case. By recognizing that a clean, sturdy surface isn’t always around when dressing your hot dog, these designers could identify the problem to be solved; single-hand condiment dispensing. 


With this problem definition, they could develop a novel, low-tech solution. 


 Conclusion 

As you can see, a Use-Case Analysis is an effective means of turning your product idea into a product that truly stands out.


By considering the User, the User Interface, and the Use Environments alongside your Use-Case, you can quickly identify the critical problems to be solved for your customers. 


Once you do that, it is simple to create thoughtful and unique features that fulfill your customer's needs before they even know it is something they need. 


 How to perform a Use-Case Analysis? 

So now that you have a bit of an idea of how a Use-Case Analysis can help take your product from average to extraordinary, you probably want to try it yourself. 


If you would like a Use-Case Template, sign up below, and we'll send you ours, along with some explanations and examples on how to use it. 


By joining our community, you will also gain access to periodic deep dives like this one, plus other content.

Join our Community

* indicates required
May 5, 2026
Why Zero Inventory Is the Goal — And How a 27-Person Shop Actually Gets There
torue wrenches
April 30, 2026
When a calibrated torque driver fails an in-house check after it's already been used on a clinical trial build, the question worth investigating isn't whether the tool is broken now. It clearly is. The question is whether the units built before the failure are still within spec, and whether you can defend that conclusion with evidence rather than assumption. A few weeks ago my Director of Quality came to tell me one of our torque drivers had been dropped. We tested it in-house right away and it was reading out of spec. Torque drivers get dropped, you replace them, you move on. The complication was that this particular wrench had been used the week before to build five units for a client's clinical trial. The wrench had a clean recent record. It came back from a full external calibration six months ago, with another six months of useful life ahead of it. About a month before the clinical build we'd spot-checked it on our in-house calibrated torque checker, and it was in spec then too. So when it failed yesterday's test, the obvious story was that the drop had broken it, and the obvious story was probably right. The problem with stopping there is that "probably right" doesn't survive contact with a regulator, and it doesn't really survive contact with a thoughtful client either. We were either going to show that the five clinical units were still good, or we were going to tell the client they weren't. Splitting the difference wasn't an option. Did the drop cause the calibration failure, or did the tool drift earlier?  Honestly, we don't know for certain. The drop is the obvious cause and probably the real one, but we can't rule out earlier drift, and it turns out we don't need to. Whether the drop did it or whether the tool had been creeping out of spec for weeks, the only question with practical consequences is whether the screws on the clinical units were torqued to a value that puts them at risk. So we worked backwards from that. What was the nominal torque setting, how far out was the wrench reading, in which direction, and where in the assembly was it being used. How do you check a torque wrench when your checker doesn't reach the working range? The wrench is an adjustable torque driver set to 5 Nm for a single joint in the build. It was going out for full external calibration regardless — that's not optional after a known impact event — but we wanted a data point quickly. Our in-house checker only goes up to 3.5 Nm, so we set the wrench to 3 Nm and ran it. It read 3.4 Nm, about 13% high. Direction matters as much as magnitude here. A wrench reading high means the operator hits the click later than they should, which means the screws received more torque than spec, not less. That is a meaningfully different failure mode than a wrench reading low. Is over-torque on a screw a risk to the assembly? This was where my Director of Quality and I started disagreeing, which is exactly what's supposed to happen. My read was that over-torque on this joint isn't a loosening risk. The screws are tighter than intended, not looser, and a tighter screw doesn't fall out. Quality pushed back that you can over-torque a screw to the point of stripping the threads, at which point it doesn't matter how high the tool was reading because the screw isn't holding anything. Fair point, and one I had a counter for. A stripped screw doesn't torque. The wrench never reaches the click, the assembler notices the joint isn't behaving the way it usually does, and the unit gets flagged. Our senior techs didn't flag anything on those five builds. Quality still wasn't satisfied. Even short of stripping, sustained over-torque can fatigue a joint and let it back off in service. That one I didn't have a clean answer for. Why a chemical thread-locker resolved the question What got us unstuck was a detail neither of us had on the tip of our tongue. Our manufacturing engineer, who has been close to this project from the start, mentioned that the joint in question also gets Loctite. That changed the picture. The over-torque was bounded at 13% above spec, not double. The screws weren't stripped. And the chemical thread-locker provides retention that doesn't depend on preload at all. Between those three facts the joint is fine, the units are fine, and we can defend that conclusion with evidence instead of assumption. What goes into a Non-Conforming Material Report (NCMR) for an out-of-cal tool? The rest was process. We opened a non-conforming material report on the torque driver with the full timeline, the measurement data, the failure mode reasoning, and the conclusion about the clinical units. Then we told the client. They'll have questions, and they should, that's part of why they hired us, but the rationale holds together and the records are auditable. The broader takeaway I don't think we over-complicated it. The temptation in this kind of situation is to take the convenient explanation, write a short report, and move on, because the convenient explanation is probably right. You don't get credit for being right by accident in a regulated environment. You get credit for being able to show your work. When Ops and Quality disagree, the disagreement is doing useful work, and you should let it run a little longer than feels comfortable before reaching for the answer. The other thing is that whoever is closest to the actual build usually knows something the people running the meeting don't. Neither I nor my Director of Quality remembered the Loctite. The engineer on the floor did, and that detail closed the case. Written by Jordan, Director of Operations at Engineering CPR — a Toronto-based ISO 13485-certified medical device contract manufacturer specializing in high-mix, low-volume elect ro-mechanical assemblies, cleanroom manufacturing, and box builds.
April 28, 2026
Why smaller service organizations beat the giants — and the gamble of an underfunded startup
More Posts