Laws of Early Adoption: Lessons from Apple, Newton, and Salesforce

This post explores the risks and rewards of early technology adoption and offers practical considerations for deciding when to embrace new features.

The Apple Falls Straight Down

Does anyone remember the Apple Newton? I don’t blame you if you never heard of it. It was introduced in 1993 and was gone, in a technological blink of an eye, by 1998. Why? Because while it was a good idea it was poorly executed. Trust me on this because - true fact - my dad bought a Newton and replaced it not long after with the newer and better Palm Pilot.

The key issues with the Newton were, according to the Museum of Failure, "it was launched far too early and its incomplete technology, like the frustratingly slow and inaccurate handwriting recognition, quickly killed the hype. The Newton became synonymous with failure, and was mocked by comedians and on The Simpsons.”

So to borrow from the Newton's namesake, for every action there is an equal and opposite reaction. Released too early and gone too soon.

Compelled to Change…

Steve Jobs ditched the Newton product quickly after he returned to Apple in 1997. It’s interesting, though, that the business process of releasing something early, knowing it may not be perfect, is a concept that is still around 30+ years later. This approach includes, but is not limited to, Salesforce. And we’re just not talking about net-new products, we also need to think about updates to existing products. SF Ben recently released a post by Christine Marshall titled Why Salesforce Ships Half-Finished Features (and Why It Matters). The sentence that best sums up the post is, “...many [Salesforce Releases] arrive without full parity with existing tools or the depth needed for proper enterprise use. Customers are encouraged to try them early, only to find that real production readiness often comes one or more releases later as missing functionality is filled in.”

When your business adopts a new technology, you inherently accept some of the risk associated with a product that may not have reached its full maturity. Ideally, the product’s parent company provides robust support and offers a channel to provide feedback. But in the technology universe, acting on feedback for any given product has to be factored into the company’s priorities, budget, product roadmap, available resources, etc. So to borrow from the spirit of Isaac Newton’s laws again, “Every [product] persists in its state of rest or uniform motion in a straight line unless it is compelled to change that state by forces impressed upon it.”

…But Should You?

Sometimes a business is compelled to change because an older product is no longer supported or a software update is mandatory for security reasons.Think of how many versions of the Windows operating system have been retired!

When you do have a choice about buying or using a new product, be sure to consider the following questions based on your circumstances:

1. Does availability of a product mean it is fully mature? Not necessarily. Some innovations evolve into indispensable tools (smartphones), while others never quite live up to their promise (sorry, Newton).
2. Are future iterations of the product on the company’s roadmap? If so, determine if you need to take action now or if you’re in a position to wait a few releases so the product has time to evolve. If not, you’ll want to consider what you’ll need to do to adapt the new product and if adaptations are even allowed. Be open to adjustments to your business processes, but don’t compromise business-critical procedures.
3. Are you deciding whether to stick with an older version of a product you know will eventually be discontinued or going with the newer, less-tested version of the product? The newer product may not be as robust (yet), but it’s more likely to receive the majority of investment and development moving forward.
4. What documentation, customer forums, and other resources exist for the new product? And beyond that, consider the time and effort you’ll need to manage the learning curve and troubleshooting.
5. Do you have the capacity and budget to create necessary, if temporary, workarounds until a feature becomes available? And if so, are you prepared to walk back those workarounds later? Short-term fixes can become long-term liabilities once a given functionality is available out-of-the-box.
6. When it’s time to pilot the new product, are you able to experiment in a lower risk environment and/or limit it to a subset of users? Using a staged approach helps you identify and rectify potentially critical weaknesses before going company-wide with your deployment increasing user satisfaction and adoption.
7. Does the new product provide functionality that unblocks existing limitations or reduce reliance on manual workarounds? While early adoption may require some patience as the product evolves, new functionality can deliver meaningful improvements in efficiency, user experience, and success. Weigh those potential benefits against any remaining gaps to determine whether the value you'll gain today outweighs the functionality you're willing to wait for.

Conclusion: Know Your Limits

Committing to any new technology requires understanding the full scope of what you are implementing. Balance your enthusiasm with thoughtful planning and research. By applying this calculus <cough> you ensure your leaps forward land on solid ground. After all, Newton’s scientific principles apply just as much to technology adoption as they do to gravity.

Unsure where to start? You don’t have to navigate these decisions alone. Arkus has been a trusted Salesforce partner for 16 years and more than 3,100 projects, helping teams bridge the gap between innovation and stability. Reach out to us, and we'll help you apply a little Newton-inspired thinking to your Salesforce strategy so your next project builds momentum instead of learning from a Newton-style fall.

BONUS! Here’s an Excel worksheet you can download to review each topic, record notes, and categorize the question as “not started”, “on hold”, “approved”, etc.