December 30, 2019

Hack Week Recap: “Teemwork” Makes The Dream Work

At Bottle Rocket, we occasionally take time out of our week to focus on exploring new technologies. We call these “Hack Weeks” and they generally consist of small teams forming and meeting for an hour or two each day to try out some new ideas.

In early December, we had a hack week around office apps that we called “Teemwork Makes The Dream Work,” a play on words that uses the Teem moniker for an extra level of puns. We had several teams explore integrating with Teem, and several that worked on other ideas. With Hack Week, anything is on the table! So let’s dig in to a few of the ideas we saw:


Tyler Milner, one of our iOS Jedi, decided to dig up an old Rocket Science project of his called BR Ice Box. The project observes the temperature readings from the Bluetooth beacons around the office and stores that information in a Firebase Realtime Database, displaying a list of all of the beacons and their corresponding temperatures in a list. The main idea of the original app was to make it easy for people to figure out the warmest/coldest areas of the office.

For hack week, he decided to build upon this project, extending the functionality to also send the temperature readings to the Teem API. In the Bottle Rocket kitchen, we have a large television that shows a list of meeting rooms and their current availability. His goal was to also display the temperature information that the app picks up on that screen as well, so people could get a sense for office temperatures without needing to download or use an app.

Overall, I didn't get very far in my implementation of the Teem API since it took some time to write the code that executes the Teem API's OAuth flow. I did get the OAuth flow working, and was able to successfully get an access token and verify I could hit Teems API to get a list of room information, but I didn't have time to take my temperature readings and execute the necessary PATCH calls to attach my temperature readings to each meeting room.

Tyler Milner

Hack Week doesn’t require successful completion of the projects that are started, the learnings from the experimentation lead to more ideas. Next up was an experiment with using a keyboard within iPad apps.


John Davis explored using a third-party framework to expand an application’s support for keyboard-based navigation.

I believe great keyboard support sets apart iPad and Mac applications that feel well considered and accessible from those that feel preliminary. The need to discover efficient solutions and patterns to implement this results from two fronts: Apple’s allowance of iPad applications to run on Mac, and a drive to better support accessibility standards that require keyboard controllability.

John Davis

The framework John explored is named KeyboardKit and is developed by Douglas Hill.  The demo app highlighted components, like tab bars and navigation bars, provided by the framework that come with easy to use support for invoking buttons and navigation actions via the keyboard.

As with most hackweek projects he was short on time and not able to explore much more, but he found the framework falls short in the same ways that Apple’s provided tools fall short. That said, it helped him learn how simple it can be to add these interactions to an application and provide a more complete experience to users.


Several weeks ago, a few Rocketeers discussed the idea of using a Slackbot as an internal test bed for analytics and user engagement tools. For Hack Week, Jason Brewer was interested in the effort it took to develop a Slackbot and how feasible or successful this idea might be.

I found that developing an intelligent Slackbot was as easy as getting an API key and standing up a Node JS server. Then I needed something for it to do so I grabbed several easy public APIs that returned nice JSON and connected them to key words the Slackbot watched for.

Jason Brewer

To bring in the analytics and engagement element, he had the idea to just let users engage the Slackbot with no context or information about its features and collect analytics on the discovery of its ‘random’ features. Using the workspace we have as a result of our partnership with Amplitude, he integrated an Amplitude package into the bot and defined events to track:

  • User joined the channel
  • User asked for help
  • User asked for a clue
  • User ‘discovered’ a feature (by typing one of the key words that triggered the feature response

By gamifying the interaction, he was able to collect data from other Rocketeers who played with the slackbot. Few people found all the features, but quite a few people participated and enjoyed interacting with a rudimentary AI. He was able to collect data around which features were the easiest to discover, and how the clues given by the slackbot impacted the successful discovery of more features. This kind of analysis is similar to what we see in our clients’ analysis, so it was nice to experiment with a version of this ourselves.

Hack Week is a great time to explore new ideas, and experiment with technology we have been following. We never know where these ideas could lead, and if you any questions, or would like us to explore ideas with you, feel free to reach out. [Link to contact us page].

October 10, 2019

Why Amazon is your competition–no matter what business you are in

Whether you know it or not, you are competing against Amazon. And Netflix. As well as every other company in the world that engages customers digitally – which is just about all of them.

I say that as someone who’s been hired by dozens of Fortune 500 companies and many other household brands to help them find, engage and keep online customers. It’s work we’ve been doing for more than a decade now, work that has put us in a position to know as much about contemporary customer engagement as anyone.

So, when I say you are competing against Amazon and others, it’s important to know that I don’t mean it figuratively. Even if you’re not in the retail space, Amazon and other digitally-forward companies are your competition for two reasons.


The first is that most customers are digital customers now, regardless of their age. We call them “connected customers.” Their use of technology to engage with brands is so pervasive that it is no longer a trend, but instead the new normal. 

Connected customers use apps on their phone or other digital interaction points to do just about everything. They purchase more things online than in person. They almost always start their shopping search online even if they buy it offline. They stream most of their entertainment and essentially do most of their brand interactions via a digital brand experience, whether that be an app, a website, an Alexa skill or any number of other digital channels.

For the most part, this is pretty much everyone. This is such a way of life, it’s likely that large percentages of your customers, no matter what type or how large or small your business is, have grown to be accustomed to engaging, superior digital experiences across the board.

That’s important because the second reason Amazon is your competition is that all digital customers judge all digital experiences against the best, and worst, digital experiences they have ever had with any company. It’s a consequence of the global, on-demand, digital marketplace that puts any convenience, every store in your hand.

Today’s customers no longer judge your performance against others in your marketplace, they judge it against everyone in every marketplace.

Why do they do this? Because connected customers look at everything as an experience. And they compare good and bad experiences, not directly competing products and services. When they shop at Zappos it’s about their customer experience, not the shoes.

They don’t compare their banking app to another bank’s app. They compare it to Uber, Hotel Tonight and, of course, Amazon. And once they have a delightful digital experience, that becomes their expectation for all experiences.

In other words, it doesn’t matter whether you sell land or landscaping or lanyards, your customers expect your digital experience to be at least as good as whatever their best digital experiences have been elsewhere – Amazon or Nextflix or whatever.

Increasingly, across all sectors from airlines to fashion magazines, from alcohol to finance, customers respond well to simple, well designed experiences that are personalized, contextual, and frictionless. And the key is, connected customers not only like great experiences, they have come to expect them, from everyone, including you.

And if you cannot or do not engage your customers in ways that are unique to them, responsive, and simple, you risk losing them to someone who does.


Go ahead, blame Amazon if you want. But you’d also better understand that it’s no longer good enough to build a better mousetrap (aka product or service). According to Salesforce, 80 percent of customers say the experience is as, if not more important, than the product or service they receive in said experience.

Not to be too blunt, but those who don’t understand that customer experience is the product will perish. It’s simply that simple.

Companies used to think that their customers were more likely to die or divorce than change banks or grocery stores. Digital disruption has changed our lives forever, and digital Darwinism is a relentless force pushing its way through every industry.

And yes, it’s tough to know whether to run and hide from this or take it head on, especially if you’re a legacy company with a lot to lose if you get the next move wrong. If you built your brand and your customer base serving customers a certain way, it’s tough to adapt and continue to succeed when the rules of the game keep changing.

It’s confusing and frustrating to have to change your mindset or culture, to go from competing against those in your market to competing against everyone everywhere. And sadly, many haven’t been able to do it.

But these new rules also offer an amazing opportunity for those who understand them and are willing to invent and iterate. Those companies and company leaders can win new customers at an unprecedented scale. A great brand experience has impressive ROI for your business.

In fact, 67 percent of customers say they are willing to pay more for a great experience (also according to Salesforce). The nice part of being in a global competition is that it’s basically anyone’s game to win.

The first step, the most important step, is admitting to yourself that you are now in the experience business, competing against every other company who knows they are also in the experience business. Once you change your perspective, everything looks different.

This piece was originally published at

June 7, 2019

Behind the Scenes: How Two North Texas Companies Are Reshaping the Pet Industry

Two years ago, when Bottle Rocket, an Addison-based technology company, and Animal Supply Company (ASC), an Irving-based distributor of specialty pet products to independent retailers, first met, neither company could have imagined where their journey might take them.

Fast forward two years, and the results of the partnership are not only changing the way ASC does business, but also disrupting the almost $100 billion pet industry.

*As originally published on*

Continue reading on Dallas Innovates.

January 14, 2019

The Shelf Life of A Mobile App

With technology changing so fast, can mobile app code get so out of date that it makes more sense to just throw it away and start over? How long does an app last anyway? Let’s take a deeper look.


Well, yes. For apps that are written, released to the store and never touched again, a complete code rewrite may be necessary within one to three years. This can be due to changes in the underlying operating system, a new mobile device with a unique screen size or format (like when iPhone X came out with the "notch"), or new security requirements (like GDPR). App changes could also be forced by changes in web services that your app is depending on, by branding changes required by your company or really any number of external factors.


The good news is, if your application is being actively maintained, a complete code rewrite should never be required. Proper maintenance means that as new features are added, the underlying code is modified to support those new features, and other parts of the code may also need to be rewritten over time in order to support new platform releases. This code maintenance is often referred to as refactoring.

Refactoring is the process of updating app code to make it cleaner, more efficient, more performant or better structured. Refactoring also allows you to modernize your codebase by taking advantage of the latest development techniques and best practices.

Keep a backlog of technical debt, and make sure that each release contains both improvements to the codebase as well as new features. Technical debt is just what it sounds like -- a list of things in your code that you know need to be updated and improved in order to make the code cleaner, more efficient and less buggy. Often, technical debt is the result of consciously taking shortcuts during the development process to avoid obstacles or get to market faster (sort of like procrastination on creating the optimal solution to a problem).


The key is to continuously evaluate the codebase to ensure it doesn't stagnate. Any time a new feature is introduced, your development team should assess if refactoring is necessary in the existing code before the feature is implemented. It is also important to adopt the latest changes to external factors that affect your app -- things like platform releases, third-party SDKs and API updates from your web services team.

Sometimes, a platform will make a major change that impacts the entire codebase, but it is still important to take an iterative approach since this helps you build upon your existing code and therefore reduce the risk of introducing issues. When Google released Kotlin (replacing Java as the preferred development language), we took an iterative approach across our organization. First, we rewrote unit tests in the new language to get familiar with it. Next, we started to develop all new features using the new language, which allowed the codebase to evolve while still maintaining interoperability with the existing code. Finally, we actively worked to convert to the new language, file by file, as we touched each area of the app. With this approach, we reduced the risk of introducing issues significantly since we were still using underlying code that was tried and true.


Only if the app code has been unmaintained for a considerable amount of time. In this case, it can become more time-consuming to update the stagnant code than start from scratch. My company used to work on games but got out of the business a couple of years ago. One of our games was still being used by some consumers but stopped working with the release of iOS 11 when 64-bit became a requirement. Unfortunately, since we hadn't touched it in years, it would have required a full rewrite in order to get it working. All the dependent libraries had new versions, and iOS had new requirements and features that would have forced a full recompile. Had we been keeping this app up to date as we went along, iOS 11 would have been an easy update, but since we ignored the app for several years, it ultimately ended up not worth the investment to update it.

Refactoring is less risky and more economical than rewriting. Without question, rewriting an entire app from scratch is risky. Invariably, teams end up uncovering new issues in the field. It is much safer to build upon the existing codebase and improve it over time, testing one update at a time, than to completely start from scratch. It is also more cost effective due to the risks associated with complete code rewrites and the implied costs businesses already budget with these experiences. Only in rare circumstances would a complete code rewrite be more economical.


Not at all. At times, a new feature might take longer to implement if refactoring is required on the underlying code before the new feature can be built on top of it. However, that is a small consideration as compared to rewriting the entire application just to add a single feature.


Refactoring to Patterns by Joshua Kerievsky is a book that is widely used by software developers at my company -- we have several copies in our library. We also have quarterly training sessions on software design patterns and refactoring, which are presented quarterly to the entire development team.


  • Your app doesn't have a shelf life!
  • Refactor code when new features are introduced to the app or the operating system.
  • Include code improvements in each release, in addition to planned features and bug fixes.
  • Actively maintaining your apps is more economical and less risky than rewriting your app from scratch.

This piece was originally published at

November 20, 2018

From Design Sprints to Proof Sprints

“Will this reliably integrate with our app?”

“Would users even want to use this feature?”

“How will we notify users?”

Simple questions, at face value. But any seasoned product or project manager knows there are no such luxuries. These inquiries could have sweeping implications for the duration and cost of a project. Even a simple “yes” or “no” can be followed by a storm of follow-up questions that cast a fog over future estimations or derail a feature set entirely.

At Bottle Rocket, we utilize a proven methodology to help clients investigate the unknowns and get answers in as little as one week. Our Proof Sprint methodology — a process for solving and testing ideas in as little as five days — is inspired by Google’s Design Sprint. Although the two processes are similar, one key difference is that Bottle Rocket’s Proof Sprints are specifically designed to answer questions beyond experience design (XD) and always begin with a hypothesis and end with a proof where Google’s Design Sprints center around XD.  Whether the result is accepting or rejecting the hypothesis, the exercise can provide key insights into a major project without pulling valuable resources from other teams.

4 Types of Proof Sprints

We’ve identified four types of Proof Sprints, each covering distinct project challenges and providing answers where our clients need them the most:

Foresight: As the name implies, a foresight Proof Sprint is forward-looking. It takes into account OS updates, upcoming technologies or trends in mobile, as well as digital services, to rapidly prototype a new offering or to find out how the new tech meshes with existing technologies.

Feature: These sprints test assumptions around new features in a product or roadmap. The outcome of a feature sprint might even find that a feature needs to be reduced, rethought, or possibly even removed.

Focus: A focus sprint is similar to a feature sprint but is based around the product’s user or workflow. As such, focus sprints work to reduce friction and improve efficiencies within the application.

Feasibility: A feasibility sprint is the most tactical Proof Sprint. The ultimate goal is to find out, “Does this work?” Does this SDK work in that technology stack? Does this database technology hook into this front-end tech via that API? Rather than making assumptions, a feasibility sprint quickly offers a definite answer on whether a technology approach works or not.

The result of a Proof Sprint can range from proof-of-concept for an idea, a prototype for a challenging spot within a project, or even shutting off a path the project was heading down because the sprint uncovered the idea wasn’t going to work. Proof Sprints aren’t intended to just validate an idea – knowing when to stop pursuing an idea can save valuable work hours and investments exploring possible solutions.

While every Proof Sprint is different, each follows a five-step template that is typically executed over a five-day workweek and includes a combined team from Bottle Rocket and client stakeholders.

  • Mapping the scope of the sprint, determining what success looks like and how the topic of the sprint impacts the customer.
  • Sketching and hands-on micro solutioning using whiteboards, sticky notes and 3×5 cards followed by looking at, discussing, and voting on the results.
  • Determining which of the sketched solutions move forward and modifying them to meet project requirements.
  • Actually building a prototype from the sketches that moved forward in the sprint.
  • Testing with a series of actual users.

Built for Results

Many things can be simplified through collaboration and uninterrupted thinking – which often is hard for fast-moving teams to accomplish. Roadblocks can cause projects to stall, or maybe six months into a project an issue arises that seems impossible to overcome. By leveraging Bottle Rocket’s Proof Sprint methodology, we are able to help our clients gain understanding quickly and with certainty in a matter of five days rather than what could take up to six months to uncover. It’s always less expensive to fail fast rather than to fail slowly. One Bottle Rocket client has even cited that via our Proof Sprint methodology, they were able to uncover more insights in just two days of the process than they had been able to on their own over the course of three months.

Proof Sprints have proven to be very effective in a variety of engagements across a range of industries and clients. Through Proof Sprints, we have investigated the optimal way to present information to a listener that is driving or traveling in an automobile. We have worked with a retailer to better understand their in-store customer flow, ultimately proposing more than forty ideas to optimize customer experiences and created four prototypes to test. Some clients have leveraged Proof Spints to test backlogged innovation ideas and validate them with users while others have examined the feasibility of integrating new technologies with mobile devices.

“Proof sprints are just another technique that’s consistent with our values, our culture and the way that we work. We love that our clients look to us to help them overcome these obstacles, and ultimately help them be more successful on their daily journeys,” said Monte Masters, SVP Solutions and Delivery.

Continue reading on Dallas Innovates.

© 2020 Bottle Rocket. All Rights Reserved.