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!