09 June 2015

The Salesforce Hacker Way

This post is dedicated to the innovation exchange students who visited Salesforce on their recent tour of Silicon Valley companies. Innovation exchange is a summer program offered by my alma mater, James Madison University (JMU).

As JMU alumni, a couple of us here at Salesforce hosted a question and answer session for the students in this program. The panel members came from product, engineering, design, and analyst relations.

The students came prepared with a set of great questions like:

  • How do you know when you have enough product to launch?
  • How do you know when to kill a product?
  • How do you take an idea to market?
  • How is Salesforce different from Dropbox?
  • Who competes with Salesforce?
  • How do you get a job out of college?

We shared our perspective about what it means to work as a team building products that customers love. We talked about ideas like launch vehicles (e.g. pilots vs betas), about getting the right people in the design room early, and about our experiences getting our first jobs out of college as well as the meandering path that led us all to Salesforce.

It was a great session and it got me thinking about sharing some fundamental product guidelines that I call the Salesforce Hacker way (in priority order because I'm a product manager and that's just how I roll):

  • Have faith. Not faith in the religious sense of the word but instead faith in yourself and your team. Otherwise, how will your ideas survive the dark night of other people telling you to work on other priorities first?
  • Figure out what's most important. When stack ranking ten stories, there's the first priority and then there's everything else. And whatever you choose, someone will tell you it is wrong. See rule one. Rob Woollen, former SVP of platform, gave this tip to me.
  • People over technology every time. Creating new products using new technologies like BigData for the Internet of Things use cases using Agile methodology with Full Stack developers may win you a game of engineering bingo. But if it doesn't solve real people's problems, what good is it? It's like a tree falling in the forest and no one being around to hear it.
  • Always be listening. Sales has their mantra, 'always be closing'. But for product, it's listening. Incidentally, when people say they are good listeners, they're talking, not listening. Listening is a skill everyone needs to develop; even those people who think they're good at it. 
  • Fail fast, fail often, fail spectacularly. Fear of failure blocks innovation. Learning from failure enables the next product to be better. Make sure your product organization supports your ability to fail as much as your ability to succeed. One of my best learning experiences came from a product that never launched leading to my next product being a success.
  • Complex designs lead to simple user experiences, simple designs lead to complex user experiences. How can you scope, constrain, and deliver the minimal amount of product necessary to trade customer value for feedback. The best feedback comes from less product, not more. I got this gem from the venerable Craig Villamor during a PTOn project a couple of years back. PTOn is where you take time out to work on a project that is not necessarily related to your current goals or team objectives.
  • Iterate, iterate, iterate. The longer a product stays in design or development, the bigger the chance of it never launching. Iterating enables a feedback loop from customers which will influence a roadmap of enhancements. 
  • Change takes courage. Designing and delivering a product may mean changing someone's concept of how things currently work. Treat that transition with respect and find ways to overcome the fear that comes with any change.
  • Stay calm, especially when everyone else isn't. This one is pure psychology. When stressed, our fight or flight reflex takes over. But what if there was a third option? When everyone else is stressed, a calm voice of reason can diffuse almost any situation.
  • You'd be amazed at what a smile and question can accomplish. Seems silly but keep in mind that everyone in the product lifecycle will protect resources, over estimate time or effort, and challenge ideas or priorities. These are actually good things to have in a product lifecycle. So keep smiling and don't be afraid to ask a clarifying question. My favorite starts with, 'why...?' and usually ends with, 'if you had this product, what would you actually do with it.' 
  • Transparency and honesty is critical. If your not willing to communicate via a banner trailing in the sky behind a plane, then you need to question what you're saying and to whom.
  • The size of an opportunity is directly proportional to the size of the problem. Keep looking for ways to disrupt people's mindsets and be ready to embrace it when it comes. 
  • Momentum is not the same as inertia. Never dismiss the power of momentum or how hard it is to start building a product. Never mistake inertia for forward progress. Products die sooner from inertia but get built with the right amount of momentum. 
  • Written specs are out of date as soon as the first person reads them. Requirements come from the tests and the documentation comes from the code. Everything else is a well articulated conversation between partners who have taken ownership of an idea.
  • Have Fun. Building product isn't easy but it is a lot of fun. If it's not fun, find a new job.
  • Come up with ten impossible ideas everyday. This exercise reminds me about possibilities in the face of compromise and even the basic laws of physics. This exercise actually originated in Alice in Wonderland.
I don't really expect anyone, including the students I met last week, to follow any of these guidelines. In some situations, I don't even follow all of them. That's why they're called guidelines.

It took me a long time to learn them through a set of experiences and challenges that culminated in successful products that I'm truly proud of. Many of these guidelines are inherited, borrowed, and stolen from the incredible people I work with on a daily basis. But if you work with product or aspire to build incredible products one day and you don't have any framework already, you might find some minimally viable goodness in these words. And from their, iterate, iterate, iterate.

That's the Salesforce Hacker way.

01 June 2015

Cloudlock Event Monitoring Viewer

Event Monitoring makes downloading log files easy using the Salesforce API. 

But what happens when you just want a quick look at the events in those files? And how can you easily map the location of each event based on the IP address?

API first features like Event Monitoring make it easy to create apps that meet a wide set of use cases. Last week's blog post was about an app that makes downloading Event Monitoring files easy. This week's blog post is about an app that makes it easy to view event log files within a salesforce organization.

Cloudlock, one of our Event Monitoring partners, created a free app using the Salesforce 1 platform that you can install in your org.  It enables administrators to easily filter files by date and type, view events within smaller files, download larger files that may not be easily viewable in the page, and map events by IP with a Google maps mashup.

Cloudlock also provides an integration with Report Exports as well as a host of other incredible security features with their full paid for app offering. You can read more about it and visualizing anomalies by clicking the Learn More button in the app. 

You can install this app using this link. It's free to use and provides access to your Event Monitoring data within your salesforce organization.

It's now easier than ever to view and map your Event Log File data with this great free app from Cloudlock!

26 May 2015

Download Event Log Files Using the ELF Browser

Event Monitoring makes downloading application logs easy using the Salesforce API.

But what happens if you don't know how to use the API? Or you don't have an operating system that makes running a download script easy? Or you've never written a download script before? Or you just want a quickly download a newly generated file without messing around with code?

Introducing the Salesforce Event Log File Browser: https://salesforce-elf.herokuapp.com/.

This browser based app, built by Abhishek Sreenivasa and the platform monitoring team, uses Ruby on Rails and is hosted on Heroku.

It's designed to enable administrators or developers, who just want to focus on the log data, to easily download an Event Log File without writing any code or setting up any integrations. This makes it perfect for both trying out Event Monitoring as well as getting started downloading log files.

The app is designed to be very simple. After logging into your production or sandbox organization using OAuth, you are presented a list of downloadable files.

Because you may have up to thirty days of files, you can filter on both the date range and the file type to find specific files that you want to download.

You can choose to either download the file by selecting the green download action icon or you can get a jump start on a simple cURL script by selecting the light blue page action. The latter action was created to help bootstrap the integration effort. For instance, if an integration specialist asks how to create a script to automate the downloads on a daily basis, you could give them this script to help get them started.

The code for this app is available publicly on Github. You can log any issues you may encounter directly to this Github repo as well. The app is licensed under MIT licensing terms, so you're free to take the source code and modify it to meet your use case.

API first features like Event Monitoring make it easy to create apps that meet a wide set of use cases. The Salesforce Event Log File Browser app is just one example.

While this browser doesn't take the place of an automated download script, it does simplify both the trial experience as well as enable simple downloads of Event Log Files without writing any code or understanding how OAuth works. And because all organizations now have at least login and logout log file types, if not all twenty nine types, anyone should be able to use it. Happy downloading!