Transforming Defects to Dollars at Grocery Outlet

Product Background

Discount grocery stores are fascinating places - walking through the aisles you can attempt to figure out what about the products made them either unsellable to traditional consumers and/or why they might be desirable by the customer segments that shop at discount grocery stores. 

In California, my favorite place to do this is Grocery Outlet, which often has both ultra-premium health food/snacks that just didn’t cut it at Whole Foods and random CPG products that were limited edition runs that missed their original selling window. 

User Experience

There were two experiences that stuck out to me recently, the first being a great example of redefining value and the second a failure to understand your customer segments. 

The first is a Jelly Belly product ingeniously called “Belly Flops” that collects all of the irregular shaped Jelly Beans and packages them together for a very low price. The beans taste exactly the same as normal Jelly Beans and the only difference is how they are shaped. This is clever not only from a naming standpoint, but also from a waste minimization / revenue maximization standpoint. Every business wants to sell as much of its “finished” product as possible, and in any business that is manufacturing physical objects, there are guaranteed to be defects. While the ideal is to first minimize those defects, generating revenue from those defects is a very close second. Acknowledging a product is a “defect” also lowers the stakes for a consumer to try it and targets an entirely different consumer segment that doesn’t necessarily care about physical imperfections but purchases on price. In terms of pricing, the 2lb bag of defects at Grocery Outlet was $2.99 before tax, whereas on Jelly Belly’s website a 2lb bag of the same defects is $9.99 while an equivalent 2lb assortment of normal Jelly Beans is ~$19.99, or 2x the price of normal Jelly Beans at MSRP, and ~6.6x more expensive than Grocery Outlet (Prices as of April 2019)!

You can see the “defective” pink, red, and yellow beans that are 2 beans fused together.

The second is variant of General Mill’s Fruit Gushers snack which adds a spicy twist to what is normally a simple, sugary snack. I, of course, had to try a box and they were indeed fairly spicy for what is normally a children’s snack! While I have no specific evidence that the product is performing poorly in normal supermarkets other than it’s presence at Grocery Outlet, one could assume that the creators of this product failed to understand their customer segments properly. I would argue that most of the consumers of this product will be children that are (a) not expecting something spicy and (b) do not, in general, like spicy foods. While the product could be a surprise hit, based simply on the customer segments that make up its market, it is likely going to be a tough sell. However, in the secondary market at Grocery Outlet where there are people like me wanting to try new products just for fun, it is a product worth paying for albeit at a discounted price. This is an interesting example of the value shift that can occur based on the selling context and customer segment of your product. 

Spicy Fruit Gushers.jpg

Dumb and Dumber Door Decals

Product Background

In February, I was in San Francisco visiting colleagues and decided to drop by the Metreon for a quick snack. As usual, a conference was happening just across the street at Moscone, IBM’s Think 2019, and advertisements covered most open surfaces advertising the conference.  

UX Issue

Conferences occur all the time at Moscone and advertisements routinely plaster over any available space around the center, but these door banners covering the East entrance doors of the Metreon were just not transparent enough to see through the door from the outside. Why is this a problem? 

It is a problem when individuals are traveling bi-directionally through a single set of doors and one set of travelers can’t see what, or more likely whom, is on the other side!

In just the time that it took for me to snap a couple photos, around a dozen people attempted to enter a door from the outside only to find someone directly inside attempting to exit the building. 

Outside looking in at the Metreon in San Francisco, CA.

Inside looking out at the Metreon in San Francisco, CA.

Potential Remedy

This problem could have been solved very easily by simply testing the material on a piece of glass before placing across an entire six door span in a commercial setting. That these doors were left in this situation implies that the individuals responsible for posting the signs took one look and decided they couldn’t or didn’t want to redo them. 

Cognitive Overload at Equifax

Product Background

  • Equifax is one of the big 3 credit reporting bureaus in the United States and is infamous for its 2017 data breach which exposed the personal information of ~143 million Americans. (Link) (PDF)

  • Their handling of the crisis was even worse and the ultimate security solution for most users (credit freezes) was further undermined by Equifax’s inability to generate random pin numbers that are used to unfreeze a user’s credit file. (Link) (PDF)

  • More recently, Krebs On Security discovered that Equifax had opened yet another security hole in their new MyEquifax portal allowing a malicious attacker to bypass credit freeze pins previously set by users if they can get past the initial challenge questions. (Link) (PDF)

  • To remedy this as a user, one needs to register on the site to ensure a malicious actor can’t act and unfreeze your credit without your knowledge, resetting your pin in the process.

    • As an aside, if you haven’t yet frozen your credit at all major reporting bureaus, you should spend the next 20 minutes accomplishing that task.

UX Issue

The challenge is that you will need an engineering degree in order to formulate a proper password! There are no less than 9 different password requirements that the user must pass in order to input an acceptable password. 

It is challenging enough for most users to have unique passwords for every site, it is another level of cognitive overload to force the user to take out a piece of paper to write out a password that they think matches Equifax’s validation rules. 

It is also interesting to note that many of the rules are likely not commonly occurring patterns, such as containing 9 consecutive numbers or spaces, and are therefore adding additional cognitive burden to users that wouldn’t have made those choices anyway. 

Additionally, having more rules counterintuitively makes the passwords easier to crack, because now there are fewer possible password combinations that need to be tried!

Potential Remedy

The potential remedy in this case is to have a competent IT team across the board, but that is unlikely to occur at Equifax.  

More seriously, the key takeaway from this post is that if this sign up flow were on a consumer app or any application where the company wasn’t a monopoly that forced users to register, most customers would balk at the sign up process and fail to progress further. There is a significant cognitive load placed on the user with each additional requirement added and if those requirements aren’t adding significant value to the user or their experience, they shouldn’t be there in the first place. 

While this is a potential UX issue in and of itself, if that many rules are required by your backend password registration system, you may be better off hiding some of the requirements that are infrequently violated and showing those requirements only when violated by the user, reducing the cognitive load for most of the users on the platform.

The Optimal Customer-Driven Release Frequency Formula


  • Why does understanding optimal release frequency matter?

    • Understanding and acting upon what drives an optimal release cycle ensures that the value your team delivers is ultimately absorbed and utilized. 

    • Delivering value at a pace that stakeholders are unable to utilize is only marginally better than not delivering that value at all, with the marginal value difference consisting of the hope that those stakeholders will utilize that value at some point in the future. 

  • The Optimal Customer-Driven Release Frequency Formula

    • Determining how frequently product and engineering teams release changes can be a contentious topic within organizations, but it should ultimately be based on two values, which are themselves multi-factorial.

    • The following formula optimizes for product success over the long term, and while release cycles can be based upon other factors, those factors are typically short term/single objective focused instead of process focused. 

    • At the highest level:

      • Optimal Release Frequency = (Average Time Required for Internal Stakeholders to Absorb Releases + Average Time Required for External Stakeholders/Customers to Absorb Releases)

        • Ex = 6 weeks for Internal + 6 weeks for External = 12 Week Release Cycles

        • Note - Sometimes these activities can be done in parallel.

      • Average Time Required for Internal/External Stakeholders to Absorb Releases are each composed of time required for [Training + Documentation Updates + Usage]

    • Full Formula 

      • Optimal Release Frequency = 

        • Internal Stakeholder Training + Internal Documentation Updates + Internal Usage

        • External Stakeholder Training + External Documentation Updates + External Usage

  • Incorrect Drivers of Release Cycles

    • Release cycles are often principally driven by a number of reasons other than the above, which are sub-optimal in a number of ways and explored further in the discussion section. This doesn’t mean the following factors shouldn’t be considered, simply that they should not be the key drivers over the long term.

      • Internal Process - Agile says we should release every 2/4/X weeks, so that is when we’ll release!

      • Publicity/Marketing/Sales / Event Driven - We have a quarterly/semi-annual/annual conference coming up, we need new features to talk about!

      • Staff - We have enough staff to release every 2/4/X weeks, so that is when we release!

      • Competitors - Our competitors sell their customers on new features every 2/4/X, so we’ll do that too!

  • Optimal Customer-Driven Release Cycle Cheat Sheet

    • Includes formulas and factors related to the optimal CDRC (PDF), (PNG), (PPTX).

Detailed Discussion

Far too often, product and engineering teams will ship features and releases at a pace that is inconsistent with the goal of delivering the maximum amount of value to both their internal and external stakeholders. This is surprising in the sense than good product teams are theoretically the “voice of the customer” and are responsible for understanding what solutions will deliver the most value. Ultimately, the ideal release cycle delivers value at an organization-specific pace that internal and external stakeholders can maximally absorb and utilize. Analogous to the shift towards customer driven development, we focus here on shifting closer to customer-driven release frequency.

Just as it is critically important for product and engineering teams to identify the right problem and the right solution, it is equally important that those teams ensure customers and stakeholders are set up to successfully utilize those solutions upon delivery. If the release cycle is too rapid, customers and stakeholders will simultaneously be frustrated at the rate of change and their inability to learn how to leverage the new features. If the release cycle is too lethargic, customers will churn and stakeholders will yearn to play on an innovative team. 

Finding an ideal release cycle involves exploring a number of different drivers that are specific to your stakeholders and your customers, which are primarily driven by how quickly those stakeholders can utilize the value you create. These drivers converge on an optimal customer-driven release frequency formula. In addition, there are influencing factors that should be considered in determining your ideal release cycle, but should not be driving its pace over the long term.  Let’s explore the drivers that make up the optimal release frequency formula alongside each of the primary influencing factors. 

  • The Formula

    • Optimal Customer-Driven Release Frequency = Average Time Required for Internal Stakeholders to Absorb Releases + Average Time Required for External Stakeholders/Customers to Absorb Releases

    • Average Time Required for Internal/External Stakeholders to Absorb Releases are each composed of time required for [Training + Documentation Updates + Usage]

  • Drivers

    • Average Time Required for Internal Stakeholders to Absorb Releases is composed of:

        • Training - Is each internal department aware of the new changes and how to support customers?

        • Documentation Updates - Is each artifact used by the organization properly updated to reflect the new changes?

        • Usage - Are employees using or interacting with the new changes? Have they incorporated them into their workflows?

    • Average Time Required for External Stakeholders/Customers to Absorb Releases is composed of:

        • Training - Do customers understand how to use the new features? 

        • Documentation Updates - Is each artifact used by the customer properly updated to reflect the new changes?

        • Usage - Are customers using or interacting with the new changes? Have they incorporated them into their workflows?

  • Influencing Factors

    • Internal Process - Sticking to a release cadence or process that delivers change at an arbitrary, albeit consistent, time interval is largely unhelpful if customers and stakeholders can’t absorb the delivered rate of change. Many teams marshal continuous delivery or two week release cycles as proof that they are delivering significant value to the business without discussing or disclosing how much of what was shipped is actually being utilized. Shipped Value != Absorbed Value.

    • Publicity/Marketing/Sales / Event Driven - There is absolutely no product and engineering team on earth that can avoid the occasional release that is scheduled principally around a specific event or client. There will be big clients your company needs to win and features built specifically for tradeshows. It is important to accept that these situations will occur, understand that these events are exceptions to your ideal release cycle, and explain to stakeholders why these occasions are in fact exceptions to the optimal customer-driven release cycle your team has so carefully determined. 

    • Staff / Empire Building - The size of the product and engineering organization can be a factor when it is too large or over-resourced relative to the products it owns. As discussed previously in Empire Building, product and engineering teams will grow over time (Great!), but the products they are responsible for do not necessarily need to grow or change at a similar rate. In an ideal world, those product and engineering resources are reassigned to new products. In the real world, those resources stay put and justify their existence by continuing to release new features that are unnecessary at worst and marginally helpful at best. In this case, the optimal release cycle has likely shifted and product/engineering resources must shift as well. 

    • Competitors - As software consumers have become more aware of the SaaS business model, rate of value delivery and agile development have become points of differentiation in the sales process. This is unlikely to change at any point in the future as it would require massive customer re-education by sales teams that are incentivized to do precisely the opposite. It is your responsibility as the product and engineering team to educate stakeholders on the rationale behind your release frequency and the data that it incorporates. Do not assume that even though a 6 month release cycle is ideal for your customers that those same customers will automatically admit to that fact or appreciate your rationale. 

Examples & Suggestions

While your release cycle will be driven by the values specific to your customers and stakeholders, there are several rules of thumb that can be helpful, all subsequently discussed as well as summarized in the diagram below.

  • Product Complexity - As product complexity increases, the length of your release cycle will likely naturally increase. This is primarily due to the multiplicative factor of product complexity, in that for each required change management activity typically required for a new release (Training, Documentation, Usage Monitoring), each of those activities will increase in proportion to the complexity of the product. An example of this can be seen in comparing the Uber application to Facebook - both are consumer facing applications, but Uber has a significantly narrower consumer facing scope than Facebook, which allows more frequent changes around that scope.

  • Customer/Stakeholder Dedication to Product - Release cycles can be shortened if you have a fanatically dedicated customer base, either due to a natural monopoly or the criticality of your software to your customer’s tasks. Dedication matters because it will increase the rate at which customers can and want to utilize the changes that your team ships. A great example of this is Adobe, whose products are all mission critical to the media production industry and are natural monopolies in their space. 

  • Customer/Stakeholder Industry Regulation - If your industry is heavily regulated, there may be a maximum rate of change that your customers can legally or logistically absorb. This is nearly zero for consumer facing applications whereas it tends towards infinity for nuclear power plant operating systems. This point is less a commentary on whether the regulation is justified or not, and more focused on determining what effect it will have on your release cycle. 

  • Dedicated Change Management Resources - If your company has an appreciation for change management and appropriately staffs training/documentation resources, it may be possible to dramatically shorten your release cycles. For example, if your customer success team is running a webinar on a regular basis to educate customers on upcoming and already released features, your organization can realistically ship change at a much faster pace than if change management is primarily handled by sending out educational emails that customers and stakeholders don’t read. 

The main objective is to ensure that the value that you ship is approximately equal to the value utilized by customers and stakeholders. If it isn’t, resources are being allocated in a sub-optimal fashion, and your team should consider changes to one or more of the variables discussed above.