Today was a good day

On Tuesday March 10, the team headed back to VMware’s campus to present our project idea and the work we had accomplished throughout the quarter.  With Sanjay Poonen, General Manager of End-User Computing, and other big names at VMware all in attendance, this was by far the biggest stage we had seen to date.

The slides to the presentation can be found here.  To summarize our presentation, we discussed the IT Service Management (ITSM) space, the opportunities that we found within the space, our 3 value propositions that fill these needs, and lastly we showed a demo of our product.  At the end of the presentation we were asked some questions about our product.  All of this went really smoothly and the people at VMware were extremely excited about our idea.  Sanjay was impressed enough to tweet about us after and even discussed an opportunity to present in front of the CEO of VMware.  This was a huge moment for the team: we had spent a good portion of the quarter playing catch-up after pivoting ideas fairly late in the game, and this moment was when we realized we had finally caught back up and landed at a product with tons of value.

With the affirmation of the value in our product idea and more helpful contacts at VMware, team DVation is well set for a productive quarter of transforming the idea into quality software. Who knows, we may be able to sell it someday!

DVation would like to thank Jay Borenstein for his help throughout the quarter and setting up this meeting, and Sanjay Poonen and the other folks at VMware who took the time to listen to our idea and provide some great feedback.

Prototype V3, V4 Demo

On Wednesday, February 18th the whole team headed to VMWare to meet with TJ, a Principal Architect associated very closely with the sales side, with the intent to show him our newest prototypes and get his feedback. Although in his position didn't put him close to the IT Admins we aimed to serve, we were able to learn a bit about the enterprise sales cycle. TJ also let us know that he thought out 'Integrated Search' feature was very useful and lets us know of some of the troubles the clients he had contact with had dealt with in the past. We walked away from the meeting not changing our prototype much but knowing we added value with this product and met a well-connected individual at VMWare. 

The next day, we returned to VMWare to meet with Vivian, Amit, and Denis again. This was the first meeting since our pivot, so we wanted to not only inform them of our new vision, but get some feedback on the prototypes we had developed. We focused many of our questions towards Denis, as he used to be an active IT Admin who would deal with ticketing systems.

The feedback we got was mixed. We felt that we had a hard time explaining to them our audience- we wanted to focus on those who have to deal with end-users who are often not technical submitting IT help tickets while it seemed that they believed we wanted to make a bug reporting system. This led into a large digression into Bugzilla and Helpzilla, which they walked us through. However, we did find that some features were definitely useful. Denis especially liked our Integrated Search feature which would allow for searching of internal documentation and Google simultaneously, as well as the Predictive Resolution, which would help to suggest ways to solve tickets. Amit, on the other hand, seemed very skeptical and asked questions about our user acquisition, infrastructure concerns, and other business aspects which we were not yet even thinking about. Amit later reflected his doubts about our direction in an email. 

This interaction left us with the conclusion that our application had the potential for great improvements for the IT ticketing space, but perhaps we were not presenting our value propositions clearly and concisely enough. 

Prototype V1 Demo

On Friday, February 13, Hussain and Jon woke up bright and early for the first meeting with VMware since we pivoted ideas.  We met with Terry, a user endpoint support guru, and Nate, an executive support employee.  The goal of the meeting was to learn more about the troubleshooting process from their perspective and to get some initial feedback on our first prototype.

The first thing we discussed was their day-to-day in order to better understand the work they performed.  Both Terry and Nate solved the issues assigned to them by directly working with users to solve the problem.  Nate specialized in working with executives while Terry focused on the average user.  One key insight we learned was that that 30-40% of the issues they encounter are quick fixes.

Next, we asked some questions to test some of the underlying assumptions to our idea of a smart ticketing system.  From this, we learned that many of the issues are repetitive – meaning that support is asked to resolve the same issues multiple times.  Additionally, under the current system used at VMware an article is written for repetitive issues to be added to the knowledge base.  However, Nate and Terry mentioned that these articles are frequently not used as they tend to be poorly written.  We also asked about the usefulness of logs when diagnosing a problem.  Nate and Terry said they do sometimes use logs to assist their work, but that the logs come from many sources, such as from logs from iOS devices, desktop computers, servers, etc.  The many sources of logs present a difficulty if we wanted to create software that could manage these logs and then diagnose problems from them.

Lastly we showed them a very rudimentary POP (Prototype on Paper).  Although the prototype was quite simple, it helped Terry and Nature better understand our idea.  From this, they provided a very helpful suggestion — filling out a report to resolve an issue needed to be as unobtrusive for the person resolving the error.  If this process was too cumbersome and there was no apparent benefit to completing it, they were confident workers would quickly disregard filling out reports.

At the conclusion of the meeting we had some good information that would be helpful in creating the next iteration of prototype.

Needfinding with Denis

Wednesday the 4th Santi, Andrew, and Jon found themselves on the VMWare campus again. This time we would be meeting Denis, the dogfood environment IT Admin at VMWare to talk about the issues he had with the current products VMWare and competitors offered. 

Denis generously gave us an hour of his time to walk us through the current IT management solutions offered by VMWare. This was a great exposure to what the current products looked like and behaved, as well as how IT Admins traversed these products. Some of what we saw was not too surprising; boring, unflashy software. We were often waiting extended periods of time for widgets to load and render. Also Denis seemed to have to jump around from application to application to get all the information he needed- it gave the impression that there was no great dashboard for all of the information Denis wanted in one place. Another interesting thing was that Denis seemed to be annoyed by many of the visualization widgets that were scattered throughout the various applications, his preferred dashboard to monitor key statistics was very simple and consisted of three bar graphs for CPU Usage, Memory Usage, and Storage Usage. 

We asked Denis typical needfinding questions, some resulting into very specific digressions, others bearing great insight. In particular, when asked "What is the most frustrating part of your job?" Denis responded "troubleshooting." He explained that when there is a failure in his IT infrastructure it is often very difficult and time-consuming to resolve the error. Reminiscent of the first project Karthik pitched us in our initial meeting, Denis explained that there are many points of failure in these systems and some of these are outside of the scope of his job/access. If he believed there was a problem with the storage, he would have to talk to the storage guys (who might be busy). If he believed there was a problem with the network, he would have to talk to the network guys (who also might be busy). While this was happening the users he supports would be out of service. He explained that this process was very frustrating, time-consuming, and occasionally meant he would be up late in the office troubleshooting in hopes that he could fix the issue before the next work day. He also explained that all the "predictive" systems to anticipate failures that he had dealt with were "total crap." Altogether, this was incredibly valuable insight into the life of an IT Admin. 

We also gave Denis an idea of what we were hoping to build. His reaction was not very enthusiastic and it didn't seem like something he would ever use and definitely was not something he currently needed. 

Pitching "Small Data" to VMWare

On Tuesday, February 3rd Karthik came to Stanford and met us in the Gates Computer Science. The purpose for this meeting was to get feedback from VMWare's perspective about our "Big Data to Small Data" proposition. 

While preparing this pitch, we prototyped an infrastructure schematic we believed would exist when building this product. We felt this would make it clearer to Karthik what we intended to build, and would also help to distill our thoughts so our pitch was more coherent. The result of this effort was the following hand-drawn schematic. 

View fullsize

While presenting to Karthik, we explained our proposed product would take your large, inoperable log data, pass it through a "modeling layer", resulting in a small "parameterized" representative set of data with which you could "play" with your data and gain the insight you needed. Karthik seemed pleased with our buzz-word filled pitch, but expressed two main concerns: 

1. This product was mainly useful for C-Suite executives and managers, and was less intended for the closer-to-data employees such as IT Admins. Karthik stressed that although these executives were the "check writers" in his experience with the enterprise sales cycle the people we need to appeal to are the end-users (the "influencers"). In the case of VMWare this would be IT Admins, and our product failed to address their needs. 
2. This product schematic was very dependent on the "Models" node. We could make everything else perfectly, but if our modeling fails the product fails. 

This input from Karthik was very valuable. Noting the large dependence on modeling, we stressed the need for VMWare to supply us with example data so we could begin modeling. Additionally, we planned our next meeting- a needfinding talk with the dogfood environment IT Admin at VMWare, Denis. 

Meeting VMWare

On January 29th, we were able to meet our liaisons at the beautiful VMWare campus. 

View fullsize

After introductions, coffee, and gelato we got down to business. Karthik and Vivian, our liaisons, along with a more technical employee named Amit, explained that they had envisioned two main project ideas for our class. 

The first idea was a product that would intelligently identify the source of an IT infrastructure failure. Amit explained that there were many components to these large scale IT deployments, and at any given time one or more might fail, causing disruptions of service for users and headaches for IT admins. The software product would essentially be an API-of-APIs that upon request would give predictions as to which component of the infrastructure was failing. All the VMWare employees avidly expressed that this product would be extremely valuable to the company. Unfortunately, this didn't align with our expectations or hopes for our project that we brainstormed the night before at all. 

The second idea was essentially a reporting tool for IT Admins and executives such as the CTO or CIO who wanted information regarding their IT infrastructure. Karthik explained that when VMWare's customers asked for this sort of information a long, time-consuming, and expensive process would have to occur. Karthik explained that in this scenario he would have to ask another employee to retrieve and compile the requested data, who might have to ask other employees, who might have to ask other employees. Basically, the pipeline for this sort of request was long, convoluted, and not efficient. In the current ecosystem, customers have to wait as long as 3 months to receive reports regarding their data. This was one of the most remarkable and important facts we learned that day, and helped us choose to pursue this project. The "3 month" figure made it obvious to us that there was a need for a better solution, but this project direction also more closely aligned with our expectations and goal and allowed for much more flexibility in the way of implementation. We immediately expressed interest in this project. 

“In the current ecosystem, customers have to wait as long as 3 months to receive reports regarding their data.”

To give them an idea of what direction we wanted to take the project, we let them know a brief synopsis of our thoughts from the night before. Karthik let us know that despite the typically slow-moving and unsexy nature of enterprise software he thought our ideas were both extremely valuable and unique. With that, we ended the meeting optimistic of our future and partnership with VMWare. 

DVation, the beginning.

 DVation is a group of motivated Stanford seniors working alongside VMWare via CS210. To learn more, check out our About page. 

Over the next 20 weeks we will be working alongside VMWare and the wonderful CS210 teaching staff to create a groundbreaking software product. This blog will serve as a journal of the entire process, from brainstorming and needfinding to development and deployment. 

Hope you enjoy our journey.