Blue Cedar CEO on How to Build High-Quality, Secure Mobile Apps

We all use mobile apps, all day, every day. As consumers, we only see them right as an end product and don’t have any insight into all of the complexity a typical organization has to coordinate, from cross-team collaboration to integrating various technologies. What are some of the challenges and opportunities for businesses to produce high-quality mobile apps? Blue Cedar CEO John Aisien shares how product leaders can build secure mobile apps to deliver positive business outcomes.

Subscribe to the Product Talk podcast on Spotify and Apple Podcasts, and make sure you never miss a single product conversation with leading product executives. New episodes live every Wednesday.

---

On problems and challenges to using high-quality, secure mobile apps

For consumers, mobile apps appear in the app store, waiting for usage. However, a majority of people don’t know the different aspects product developers need to know before creating an app. John explains the challenges and differences from other tech development.

“First of all, mobile has a number of unique characteristics versus other enterprise software form factors. For example, cloud apps, web apps, in almost every other instance, those apps are designed for and run on form factors that are more controllable by the enterprise, be it an on-premises Web Server or even a cloud-resident Kubernetes container. Those things are generally a lot more under the control of the enterprise than a mobile operating system. Apple and Google pretty much control the entirety of the lifecycle of their operating system. The same is true for frameworks by which mobile apps are developed. So the first big difference between mobile software and other forms of software is the difference in control orientation and the difference in the primary reasons by which these form factors exist. Mobile form factors exist primarily for consumer use. They’ve been adopted for usage in the enterprise context. So that itself creates a mismatch between the traditional controls that exist for other forms of enterprise software and those that have to exist for mobile software. A good example of that, for software to actually run on Google Android or an Apple iOS, the software has to be signed with certificates or other credentials that ensure that those pieces of software have not been tampered with before they run on those operating systems. Those forms of specific controls do not exist for other forms of enterprise software. 

Another really important point is that end users’ economic expectations for mobile software are very different. Mobile software, especially those that run on iOS and Android devices, has been around for roughly 14-ish years if you sort of start the clock from the advent of the first iPhone in 2007. Throughout that time, whether you’re Gen Z, Gen Y, or Gen X, we’ve all become digital natives. One of the characteristics as an end-user of becoming a digital native is we download apps and we expect these apps to be immediately usable without any training. We download the apps, we tap them, and we want to go immediately. We don’t want to read a manual, we don’t want to go through a training course, we don’t even want to watch a YouTube video around how the app works. Even worse, when the apps don’t meet those sky-high ergonomic expectations, we silently abandon them. We don’t call support, or email someone to say, hey, this app is difficult to use, we just abandon it and move on to something else. That’s horrendous in the context of the enterprise that is spending literally, in some cases, millions or even billions of dollars on these expected digital outcomes. They have a very, very high hurdle rate to ensure that end users’ economic expectations on mobile, which is different from their economic expectations, when using SAP or Oracle, for example, making sure those expectations are met.

If put all that together, what organizations need is a form of plumbing, if you like, or a set of security control orchestration and other technologies that meet the unique characteristics of mobile software that ultimately still manifests sensitive corporate data that requires all of the necessary controls that you would expect, along with all the other unique characteristics of mobile.”

On category strategy and bringing something unique to the market

Being a breakout in technology can be tough when many exciting things are happening in the Internet of Things. For Blue Cedar, it was recognizing the lifecycle of a similar product (Web), and using that to predict where the market for mobile apps might head. 

“We experienced a number of the challenges. We were in an endpoint sort-of startup that had multiple offerings, Internet of Things offerings, but also had some fledgling mobile offerings. In that context, we had actually experienced ourselves, our customers, our prospects, both existing and potential partners, experience challenges around getting a mobile app, or developing a mobile app, or subscribing to a mobile app from someone else, and having to manually or using some combination of existing tools that weren’t really designed for that purpose, and additional tooling that they wrote themselves, trying to solve those problems. We had visceral firsthand experience of a number of the challenges. Importantly, we also had a pretty willing and very enthusiastic founding team, who combined this sort of visceral knowledge of the problem set with a real drive to develop technology, differentiated unique technology, that addressed those needs. Lastly, we also had a really firm belief and continue to have a firm belief on the eventual emergence of key trends that we felt would serve as tailwinds for the business. 

As an example, when we started five years ago, most organizations hadn’t really deployed their core business workflows: insurance underwriting and insurance, private wealth, sales and financial services, oil and gas exploration, data access in oil and gas, etc. Most of these core business workflows hadn’t yet manifested themselves in mobile apps. The majority of corporate mobile apps that we saw five years ago were for important but fairly rote functions like email, calendar, contacts, maybe room booking, a secure browser through which you could access the company’s intranet portal. 

We really felt that the economic activity that would drive true growth in our business would arise when these core business workflows, industry-specific, eventually made their way into mobile apps. We always felt that would happen sort of roughly 10 years after the emergence of these technologies in the first place, and that’s exactly what we saw in web. Most organizations didn’t really adopt web technologies as first-class, enabling technologies until sort of 10 years after the advent of HTTP, HTML, XML, and we saw a similar trend evolve around mobile. That’s what ultimately gave us the conviction to start out the business when we did.”

On best practices for digital product leaders about mobile apps

There are many bumps in the road when being a product manager or leader, areas that were learning points and places to grow from. John shares three areas where he has stubbed his toe during the process as the CEO of Blue Cedar and his years of experience as a product leader.

“The first is being ashamed about not being a whole product. We are not a whole product. You can’t use Blue Cedar to manage the entirety of your corporate mobile app lifecycle, from ideation, what should I build in the first place, to actually building the software compiling it, continuously integrating it, and ultimately securely deploying, and optimizing it. We don’t handle the entirety of that lifecycle by design. That is ultimately what our customers all do. Recognizing that there’s extreme power in being an ingredient solution, and designing one’s go-to-market, around the ingredient nature of one solution is important. In the early part of our incarnation, we tried to sell an ingredient product as a whole product, and frankly, made a bunch of mistakes as a result. The good news is we’ve now optimized our go-to-market which is very partner-driven, and partner-dependent around the by-design ingredient nature of the solution that we develop and take to market. 

The second is around pricing. When there’s an impedance mismatch between the value that you deliver and the way that you price, you’re going to encounter friction in the marketplace. For the app enhancement and the app deployment elements of our software, the unit of value is the number of mobile apps that are securely deployed, as opposed to the number of users of that mobile app. In the early incarnation of our pricing, just to kind of align with what we thought were customers’ pricing expectations, we priced based on the user instead of pricing based on the number of app binaries that we security deployed. Now, we still have an element of our solution, the runtime security enforcement element of our tech, where the true unit of value is the number of users using the software. So we continue to price that element on a per-user subscription basis, but for the remainder elements of our value enhancements and deployment, we’ve modified our pricing to suit the true unit of value. We certainly again suffered from inefficient go-to-market when we had that inconsistency inherent in our pricing. 
The third dimension is to listen to your customers but stay true to the convictions you have around the key trends that are the foundation for your innovation in the first instance. Many instances in the past, I, and my product leads, were a bit too explicit in responding to our customers of the now product needs, even though in some instances, those needs were inconsistent with the key trends around which we had conviction and around which the company was founded in the first instance. So those will be my three: Align your go-to-market with your whole product or ingredient product orientation, price based on the underlying unit of value that you deliver, and stay true to the fundamental ethos, or are foundational beliefs that are the basis of your product innovation.”