Language can be a funny thing. Words can have different meanings based on the context or the inflection of the speaker. Comedy is full of misunderstandings caused by this ambiguity, and the “dad joke” exists because of the almighty pun.

It’s not so funny when a misunderstanding costs your project an extra $10,000 you didn’t expect. Or extends your timeline. Or worse. In any type of technical project, you don’t want ambiguity. You want understanding and cooperation. 

Many organizations aren’t familiar with the concept of ubiquitous language, where the meaning of important terms is documented and shared with the whole team. When someone refers to, for example, a customer account, everyone should know exactly what that means. No one should be guessing whether that means the user profile on the website, the account maintained by a sales representative, or a stack of unpaid invoices. And if it means the user account on a website, what information and features are included? What should customers be able to do?

In e-commerce projects, this uncertainty can cost big money. Unscrupulous sales and marketing collateral from e-commerce vendors often exploits ambiguity to make fantastic promises that sound great but are never fulfilled. They promise you the stars. If, by stars, you mean these glow-in-the-dark stickers you can put on your ceiling, and not the heavenly bodies burning millions of miles away. For that, here’s a series of 17 change orders, accompanied by a 6-month delay.

Vocabulary matters. In the words of Inigo Montoya, “You keep using that word. I do not think it means what you think it means.”

We’ll go over how to avoid this problem with the classic "five whys” paradigm popularized by Toyota, along with some other practical tips.

But first, let’s cover a common scenario.

Mismatched expectations for requirements

You're reviewing proposals for e-commerce platforms, and every vendor confidently checks the box next to "wishlist functionality." You said you wanted a wishlist, and they all have wishlists. Problem solved. Time to move on to other criteria.

But not so fast.

What exactly do you mean by “wishlist?” And more importantly, what do they mean by “wishlist?”

You might envision Amazon's sophisticated system, where customers can create multiple named lists, share them with friends and family, add quantities to each item, and track what has been purchased versus what is still needed. Perhaps your customers would like to add products from third-party vendors, manage gift registries for special occasions, and receive notifications when items go on sale.

Meanwhile, your vendor might be thinking of a simple bookmark feature. Logged-in users can save products to view later. That's it. No sharing, no quantities, no advanced functionality. Or maybe they remember seeing some premium wishlist plugin for WooCommerce and assume it covers every use case.

Both of you said "wishlist," but you're talking about completely different products. The vendor delivers their interpretation, you're disappointed, and suddenly you're looking at change orders worth tens of thousands of dollars to bridge the gap between expectation and reality.

The hidden costs of "Yes, We Have That"

Of course, this isn’t limited to wishlists. We’ve seen it with inventory tracking, price lists, customer galleries, search functionality, and abandoned cart recovery. Here's why this happens.

Too quick to check the box

Many platform vendors approach feature requests like a checklist. Wishlist? Check. Inventory tracking? Check. Customer price lists? Check. They're not necessarily being deceptive. The account representative might genuinely believe their out-of-the-box solution covers your needs.

The problem is that they stop asking questions too early.

Too many assumptions

When someone says they need "inventory tracking," it sounds straightforward. Track stock levels and prevent overselling when you're out. Simple.

But what if you're a furniture manufacturer building custom pieces to order? What if your "inventory" isn't finished products but component materials like yards of fabric, wooden bases, and hardware sets? Maybe you have multiple warehouses. Suddenly, basic SKU-level inventory tracking doesn't solve your actual business problem.

When Requirements Are Clarified Way Too Late

Consider these examples from actual project discussions.

Price lists

A client requested "customer price lists," and one vendor immediately pointed to their price list module. Many times, that’s the end of the conversation. However, the client needed role-based pricing tiers. Customers would receive 5%, 10%, or 15% off, depending on the role assigned to their user account.

The vendor’s price list module was designed for custom pricing on specific product subsets, and not percentage-based discounts tied to user roles. It couldn’t handle what the customer needed.

Search functionality

"We need fine-tuned search results" could mean anything from adjusting keyword relevance weights (a configuration task) to manually controlling the sort order of every search result for every query (requiring sophisticated third-party search infrastructure). The difference in complexity and cost is enormous.

“Fine-tuned” is doing an awful lot of work in the stated requirement. We want to dig deeper into this type of ambiguity to ensure there are no unpleasant surprises. The questions will get asked eventually. We want to ask them when they are still cheap to ask.

Customer galleries

One furniture company wanted a "customer gallery" where customers could upload images of products in their homes. Simple enough, until you start digging. Do you want automatic thumbnail generation? Image approval workflows? Surface certain galleries for specific product pages? What about content moderation?

What started as a basic image upload became a comprehensive content management challenge. A challenge that can be solved, for sure, but you need to know what the actual challenge is first.

The Five Whys applied to e-commerce features

The solution to assumption-driven disasters is deceptively simple: keep asking questions. Toyota's "Five Whys" technique is particularly effective for e-commerce requirements definition. Let’s use the wishlist as an example.

1. Why do you want a wishlist?
   "So customers can save products they're interested in."
2. Why do they need to save products?
   "They can't buy everything at once, and they want to remember items for later."
3. Why can't they just bookmark the page?
   "They want to share lists with co-workers and managers."
4. Why do they need to share lists?
   "Our customers buy professional equipment, and purchasing decisions involve multiple stakeholders."
5. Why do multiple people need access to the same list?
   "Because purchasing managers create lists, but executives approve budgets, and procurement teams place orders."

Suddenly, your "simple wishlist" has revealed itself as a collaborative purchasing workflow system.

Some practical tips for e-commerce project success

• Document your business processes before discussing features. Understanding how you work today helps vendors understand what you need tomorrow.
• Map your customer journey before defining technical requirements. Understanding how customers move through your sales process reveals what functionality actually supports business goals.
• Ask vendors to demo their interpretation of your requirements, not just confirm they have the feature.
• Budget for definition phases. Spending 10-15% of your project budget on architecture and requirements definition prevents 50-100% budget overruns later.
• Create user stories, not feature lists. "As a purchasing manager, I need to create product lists that my team can review and approve," tells a much clearer story than "we need wishlists."
• Prototype early and often. Most misunderstandings become obvious when you see a working example.
• Plan for integration complexity. Every feature connects to something else in your business.
• Think about content workflow, not just customer-facing features. How will your team manage, update, and optimize these features over time?

How does Drupal Commerce fit into this process?

We don't pretend to have a perfect out-of-the-box solution for every business need. Instead, we acknowledge the truth of what we use: it’s an abstract toolkit designed to be shaped into exactly what you need. We’re not going to point you toward a pre-built module and call it a day. There are numerous features and pre-built modules, but these enable us to initiate a more productive conversation, rather than ending one.

Take the customer gallery example above. Since Drupal is a flexible framework, within 2 hours we can create a content type that lets users upload images, format them in a certain way, and organize them into galleries. These can even be associated with certain products. From there, we can refine the rapid prototype based on further needs, edge cases, or deeper discovery. You know what you’re getting.

You now have functionality that matches your requirements, and it can also adapt to your business as things change.

Specificity Saves Money

The most expensive word in ecommerce projects is "yes," followed by unexamined assumptions. Any good vendor or agency partner will want to understand your business processes before proposing solutions and stating prices. Beware of anyone who doesn’t ask questions.

And when someone promises you the stars, make sure you're both looking at the same sky.