The last deal I helped win at Dynatrace before their first RIF was when  I created a demo that provided all the visibility and power that a normal PoC (Proof of Concept) would have done – but integrated our UEM into the customer’s own mobile app.  With any complex and/or expensive technology a PoC (or PoV/Proof of Value) will almost always be required.  At the time you couldn’t get started with most of the Dynatrace solutions without a $100k-$200k outlay.  These numbers often require a Senior VP signature, if not that of the CIO or CTO.

But back to that demo – I got the satisfaction of learning something new when creating an exciting and moving demo that utilized instrumenting their own mobile app. (And yes – we won the deal off of the demo.)  I also really saw how a little knowledge can make for a skilled and dangerous (to the competition) Sales Engineer.  Hopefully you can glean something here that will make you more valuable to your employer or the sales reps you are tied to!

That experience made for a great example of where being a generalist armed with a little knowledge could lead to more closed sales.  I’d like to highlight that knowledge and give other modern examples where an SE could leverage it.  This blog post is 100% from memory with a little online research for supporting links.  I’m also making sure I don’t share anything that the client wouldn’t want to have made public.

For a little history, we were dealing with a large institution that was trying to get more of their customer interactions to happen mobile.  It would help improve customer satisfaction, drive down costs and of course all of this increases revenue.  Their mobile app had been developed by one (or more) independent consulting firms.  This meant the company had no in-house knowledge or familiarity with it.  They were worried about having performance or dependability issues.  That would be compounded by not having any visibility to exactly what was going wrong.  If a mobile app drops too low in how many stars it has (often 3 is the bottom limit) then the signups and usage drops off dramatically.

At the time I would:

1. Download the APK file from the playstore.  (Google how – it isn’t hard.)
2. Instrument it with Dynatrace’s auto-instrumenting tool.
3. Load that APK file onto an emulator on our laptop.
4. Point that emulator at our own Dynatrace install to collect information.
5. Exercise the logic of the app until we had a good visual to show the potential client.

This always made for a very powerful demo.  I’m not going to point at specific links on how to get APK files separate from having a device, or how to run an emulator on your laptop – but lesson #1 is knowing that both are simple and very possible.  I’ll give some examples later of where you might be able to leverage this for your own demos without any kind of auto-instrumentation tool.

The problem this time was that the hybrid app they used was developed with old code and the Dynatrace tool crashed when attempting to instrument it.  (For the competitors looking for FUD – this was the only time it happened in the 4+ years I was there.)  If you aren’t familiar with the term “hybrid app” then it is time for lesson #2.  Mobile apps can come in one of three flavors:

1. Native.  Apps written almost 100% in the native language of the device.  Such as Java for Android or Objective-C for iOS.
2. Web.  Take some HTML, CSS and JavaScript and build something that “feels” like a regular mobile app.  If done right, most users can’t tell the difference.  But you lose a lot of power to do things like accessing the user’s contact, calendar, SMS etc..
3. Hybrid.  They are a lot of what a Web based app have, but leverage some technology like PhoneGap to bridge between the webview and the native SDK.  Gets around the “power loss” I just wrote about with a Web based mobile app.

Since our instrumenting tool was failing I had to see what else I could do.  My first piece of research lead to lesson #3.  An APK file is basically a zip file that you can unzip, modify and re-zip up.  So I wrote a quick script that would unzip the APK file.  It would add our UEM (User Experience Management) JavaScript code into the HTML pages.  Lastly it would then re-package it.  I did have to configure the emulator to trust unsigned apps (lesson #3) – but that was pretty easy.  (Please only do that on emulators, and understand the risk if you configure your own device to trust other sites for APKs.)

Why write a script instead of just manually adding the JavaScript to the key files? If the APK file got upgraded just before the demo the old one might not connect to their servers and work.  And I wanted full consistent coverage of their application.  You never know what direction a live demo on a customer’s application is going to go.  Be prepared for as many of the paths and routes as you efficiently can!  Plus if they bought in (no pun intended) I wanted to be able to offer the script in case the costs of having their consultants add it to a new version was too expensive.  You want to remove every barrier you reasonably can.  That’s a big part of your job as a Sales Engineer.

Now this might have you pointing out that Dynatrace had a tool to add instrumentation to a mobile app.  Does that apply to what you do?  Perhaps there are ways where this methodology could be made to work.  Here are two that come to mind from recent demos:

1. Your firm sells a SaaS offering that allows the user to get help via the mobile app.  Imagine if you know you’ll be onsite (or a WebEx/Hangout) to show how your solution works, and you’ve got a little time to prep.  What if you could download their app, add the “Help” icon to several pages and tie it into your WebChat API?  The people in the meeting will so quickly understand how they could use your technology integrated into their app.  Of course you’ll want to have someone “manning” that help channel when the demo occurs, or have some way of doing it yourself to show how smooth and fast things work.  Either way it sure highlights how “easy” the solution is to integrate!
2. Your firm sells a SaaS Search platform.  With a little notice you could replace the “search” form links and logic to use your own product’s API.  You would have an extra step of having to scrape some of their product catalog to have a corpus/index of what a search could find.  But this could be limited to two or three examples for the demo and you could caution that if questions came up.  Be sure to include searches that highlight your product’s strengths – like eliminating stop words, understanding context or getting around misspellings.

That’s just two examples that have come to mind from my recent interviews.  With a little knowledge you can really “wow” your potential customers and make more sales happen faster.  If you come up with another that is okay to share please let me know!