How Companies Pivoting into Apps can turn into a Rodeo Gone Haywire
In small western towns, everyone gets excited when a rodeo comes around. It is often a key attraction and is usually held at the exhibition grounds in late summer or early fall. For towns that do not have an exhibition, an alternate venue for a rodeo can be the skating rink.
Yup, you heard me right: the skating rink.
Apart from the possibility of some of the boards getting damaged along with a bit of cleanup (okay a lot of clean-up) the rink is actually a pretty decent venue for a rodeo.
Seating, concessions, entry and exit-points for the animals and more. It isn’t perfect but it works.
A lot of work goes into preparing, running and wrap-up for these types of events; I know this because my uncle has played a pivotal role in several.
Rodeo Build-up
A couple of questions that the organisers will likely ask when setting up for a rodeo are as follows:
- Where will the bulls and horses be kept?
- Who will help with the concession stands?
- What about all the feed and water for the petting zoo and pony rides?
- Who is in charge of mustering the clowns, wranglers, announcers, safety people and all the other positions a rodeo requires?
- What about the people responsible for advertising and sponsorship?
- Who looks after all the finances?
My point in all of these questions is: if you run a small-town rink and want to put on a rodeo you will probably want to get some help.
Rink owners and their staff are likely great at helping people who want to play hockey and figure-skate. They are likely not that great at running a rodeo.
This is where my uncle comes in.
He has a ton of experience with rodeos and helps the rink manager and their staff take all the pain away from planning and running one.
Enter companies that offer a certain product or service and then decide to get into software.
How a Rodeo Relates to Applications
While they may have a line-up of internal applications and a few supporting elements to meet their own needs, this doesn’t mean companies and organisations are provisioned to be a Platform as a Service (PaaS), Software as a Service (SaaS), or any other sort of technology provider.
Take for example one company that does not believe in pre-release testing. Testing is too expensive , they cannot afford a test environment so they just roll out a new release and wait for the feedback to come in.
Hmm.
Combine this with an inconsistent release cycle and it certainly makes for some interesting situations.
All of a sudden a key feature that used to ‘just work’ is now buggy, slow, awkward or otherwise unusable by the customers.
When you pair this with the point-of-view that applications *must* be slick and responsive thanks to the well-established apps and services provisioned by Google and Amazon as benchmarks, impressions quickly trend towards the negative. No self-respecting person I know can stand crappy software these days.
This is sort of like telling the rink manager in our small-town example that they are in charge of bull-roping for the rodeo. It might start off in the right direction but because they don’t know how to control the gates it turns into a ‘running with the bulls’ event all the way down main street.
You are not a bull-rope lead-hand just because you happen to be the rink manager. Unless of course you also happen to be a bull-rope lead-hand. Which can be a thing in small towns. But in this example it is not.
Productising Inward-Facing Apps
The same is true for companies that try to stretch their operations into software and do not make the necessary preparations. Such as on-boarding and retaining the appropriate people to help with the transition from ‘Company X’ to ‘Company X Now Featuring House of Apps’.
Yes, there are many examples of apps that are considered Minimum Viable Products that some companies are eager to release earlier rather than later. This is not necesssarily a bad strategy, but not having the minimum amount of support for their MVP will very likely spell trouble.
No test environment, no consistent method for collecting user feedback and no proper set-up for continuous-integration-continuous-deployment (CI-CD) means you are not provisioned to validate your MVP.
You want your customers to think the app is worth using over a period of time.
Why give them a bunch of road bumps such as inconistent releases and features that break unexpectedly without any proper feedback channels?
Deploying applications without the proper supports in-place is a bit like being thrown out the cargo-door of an airplane without a parachute.
Companies may be eager to skip a bunch of steps in their efforts to keep pace with competitors who made a move to digital pre-Pandemic. Take for example an executive who packaged and deployed the company’s internal suite of apps as part of their value-add. Without the proper DevOps supports there will be trouble on the horizon for such a company.
Not having the right tools, training and other bits and pieces such as a platform for CI-CD means that what was initially a value-add can quickly turn into a value-subtract.
Postscript
If you plan on running a rodeo or deploying your internal apps out into the wild, be sure you have the correct people and supports prior-to. Otherwise you might want to warn main street (customers) about the possibility of lose bulls (buggy websites and apps).
What experiences have you had in deploying applications out into the wild?
