Use a “Show & Tell” to Pitch Your Product Like Salesforce

If there’s one book I wish I’d had in the beginning of my career, it’s Dan Roam’s Show & Tell. The book walks you through improving any presentation with three simple rules:

  1. Tell a story. (Have a clear narrative.)
  2. Tell the truth. (Keep it grounded.)
  3. Tell it with pictures. (Show something!)

I use Dan’s advice and templates almost every week, and I’m starting to see the pattern in other places. Salesforce’s marketing execs gave an overview of their major product offerings at a recent event, and I saw these key elements in their presentations.

The pitch for their new analytics product had all three pieces. There’s a clear story line starring a persona named Jackie, and the sense of truth is built by the realism of the scenario and the pictures of the product proving it’s not vaporware.

Strengthening Each Area

Dan’s approach can also be used as a framework for critique to improve the pitch, for example:

  • Story: The story was about 10 minutes; where could it have been tightened up? Salesforce’s other product overview videos clock in around two minutes.
  • Truth: I often find these stories work out a little too perfectly, which can diminish the credibility of the speaker/company. Writing well is hard, and attempts to add pizzaz often sound cheesy to the audience.
  • Pictures: Could the narrative itself have been expressed in pictures somehow? That would have added some clarity.

Other portions of the keynote emphasized story, truth and pictures to different degrees, and you can see how that effects the results. This video about GE Capital had top-notch production values, but contained at least three different messages:

  • Salesforce’s analytics tools make GE Capital successful
  • GE Capital helps companies like yours succeed
  • You need great analytics to succeed today

Those things are probably all true, but saying them all at the same time creates fog around the narrative. Editing can be gut-wrenching, but it’s better to end up with one clear story.

Surprisingly, there was also an piece of the keynote which was literally just a story. This wedding day disaster could have been lifted from a romantic comedy, but it wasn’t possible to include any pictures to reinforce it. It was all tell and no show, but too many people “believe it when they see it.” I’ve found an unexpected link between pictures and truth, at least for stories about products.

Product or no, your next presentation will be better as a story, with truth that resonates and plenty of pictures. Try it.

The Testimonial Pipeline: Get Reference Customers Like Salesforce

I know we just met, but will you buy my product right now? Can I put your picture on our web site as a happy customer?

No? Maybe next time.

Growing Reference Customers

A customer testimonial does not magically appear on your web site. Your relationship with them starts as a seed, and their success blooms the more your product’s value nourishes the plant. With a little luck and a lot of hard work, some of those blooms will be worth showing off.

So how, exactly, do you obtain a testimonial? Well, Agile development, by itself, won’t cut it. Marty Cagan’s “Inspired: How To Create Products Customers Love” helped me understand that shipping code every 2 weeks without changing how you engage customers gets you no closer to making them successful. Sprinting through your backlog does not create more customer value than waterfall if you dreamt up the feature set without validating demand or testing your designs. Agile offers no specific structure to engage customers, especially for revenue products with buyers outside your company.

Salesforce.com is a useful case study, since they’ve published over 100 customer success stories on their web site. They engage customers at many different points along the timeline of product development, creating what I call The Testimonial Pipeline.

The Testimonial Pipeline

A testimonial pipeline has multiple stages, similar to a sales pipeline. And just like sales, not all the customers that enter the wide end of the pipeline will come out the other side as a reference. (Repeat: you will not bat a thousand here. Manage expectations.) The stages are as follows:

  • Interview Subjects
  • Usability Testers
  • Beta Participants
  • Reference Customers

Anyone you talk to starts as an Interview Subject, even before they’re a customer. Talk to real people as early as possible to get a deep, rich understanding of the demand for your product/idea. If you have paying customers already, you should obviously talk to them as well. The way you refer to these folks is less important than what you call them.

Product managers and user researchers at Salesforce.com take the lead at this stage, and reach out to people via many channels. You want to get people on the phone or meet them in person, though you can often make an initial connection via social media. Feel free to validate early design ideas as well as the underlying demand, even though it bleeds into the next stage a little.

If there’s sufficient demand and a design idea is around 60% baked, you can have some people play the role of Usability Testers. In short, you ask the person to complete a task inside your user interface and gauge how successful they were. An interesting twist Salesforce adds: they make small improvements to the design between each round of testing. Don’t be rigorous about maintaining a control group and experimental group: the goal is to improve the design as quickly as possible.

Once the concept has matured into working software, some brave souls can test it “in the real world” as Beta Participants. When customers put the product through its paces in their own environment, you start to see the value it (hopefully) creates for them. Salesforce proudly announces which brave companies participate in their critical beta programs; usually any code is feature-complete, though it likely contains some bugs.

If these folks continue to see value after the product is generally available, they can (finally) become Reference Customers. This manifests itself for Salesforce in a number of ways: on their web site, as reviews on their AppExchange, in YouTube videos, and even in traditional print media. Their customers are the heroes of these stories.

But I’m Not Big Like Salesforce

If this all seems daunting, I have good news: you can get started today just by picking up your phone. Call someone and ask them about that idea in the back of your mind. All you have to do is have a conversation. If you want to put just enough process in place, refer to The Entrepreneur’s Guide to Customer Development and Lean UX.

Know you need to get out of the building, but having trouble with buy-in? Show your stakeholders these examples from Salesforce.com and frame it up in terms of getting reference customers and increasing sales.

And who wouldn’t want more sales?

User Experience Design for Mobile

As part of Salesforce’s “Summer of Mobile” webinar series, I presented a session on user experience design for mobile. This post is adapted from that webinar.

Mobile device use is exploding, but people can only make time for about 5 new apps every month. So as a business that wants to jump on this trend, how do you build a great product that sticks with users?

In our work at Appiphony, we use a four step process:

  1. Get Out of the Building
  2. Define Success by Writing the Script
  3. Build the First Prototype
  4. Iterate Until It’s Great

This post describes the use of this process on a real project we executed for a particular Salesforce ISV.

Project Overview

Our client provides physician staffing services to emergency departments across the United States, and wanted to dramatically increase the quality and quantity of feedback they received on physician performance. (Their baseline was a paper form in the mail with a single-digit response rate.) They had a vision to deploy iPads to the emergency departments (EDs) and get feedback in real-time.

Get Out of the Building: Customer Research

As soon as you reach an initial consensus on the product concept, perform a site visit to a location where the app will be used. You need to build an understanding of a setting to gauge how the app will fit within that setting. And based on the questions they will later ask, the rest of your team wants to understand this fit, too!

We visited two separate hospitals and observed the flow of patients in the ED. Seeing the physical location helped us understand how the patients would be able to give the desired feedback. (More on that later.)

If you want to get out of the building but don’t quite know how, check out the book Rapid Contextual Design. It’s a detailed playbook for site visits that also provides process options for small, medium and large budgets.

Define Success by “Writing the Script”

Once you have a handle on the setting, write a plausible story starring your customer succeeding at something with your app. Ideally, this story will take place in the setting you studied. (It will be much more realistic that way.)

In contrast, don’t ship features that don’t connect in a coherent way for the user. “Stick to the script” and leave out what doesn’t fit. And if you’re worried about leaving things out, don’t forget you’ve got 80% less screen real estate on mobile.

Our script is shown below in the form of a storyboard. It turns out patients have down time in the treatment room after they’ve been helped but before their prescription is ready and they can leave. And here’s the key detail that drove this home for our team: there are TVs in the treatment room to kill this extra time. We never would have learned this without the initial site visit. With that, the dev team truly “got” the concept and was 100% on board.

Start by writing your own story in words, and if you’re unsure how, About Face by Alan Cooper will lead you through the process. I recommend you make the story visual with a storyboard or comic, and for that you should read See What I Mean by Kevin Cheng.

Build the First Prototype

Now that you have a vision of success, it’s time to build your first prototype. Do this as quickly as possible, since you will change the UI, probably in a significant way. If you’re developing on the Salesforce platform, you can use the Mobile Packs to deliver something clickable quickly.

Prototyping is absolutely critical on mobile; one poor interaction detail can kill your whole experience. In our case, we ran a quick-and-dirty usability test with an elderly relative and saw him get stuck with part of the interface that required scrolling. We took it out and reworked the core navigation mechanism.

If you’ve got a sense for what the app needs to do, but aren’t sure how to lay out the screens, consult a pattern library reference such as Designing Mobile Interfaces. A resource like this lets you flip through well-documented solutions to many common design problems.

Iterate Until It’s Great

The last step is really a beginning of sorts: once you have something clickable that can stand on its own two feet, you can begin iterating with representative or actual users. And yes, you will need to iterate. It’s like preparing for the SATs:

  • You don’t want to “walk in cold.” (Some kind of practice is critical.)
  • Feedback will improve performance, but only if it’s specific. (Should I work on my essay writing or reading comprehension?)
  • Many external resources are available to drive improvements; the key is realizing “better” is possible and planning for it.

Allow for room in your project schedule to polish the interactions and flow from screen to screen. This is critical, so I’ll repeat it: make time up front to revisit the same functionality across multiple sprints to account for the tweaks you’ll need to make. On our project, we made nine (!) prototypes of the key flow before we reached the shipping version.

The New York Times bestseller The Lean Startup has popularized iteration, so many people will be familiar with this. Take a look at a related book called Lean UX to learn more about how to rework your team’s processes to account for iterative cycles.

If you’re curious about how exactly to apply polish to a user interface feature, a book called Microinteractions describes a framework for approaching this and shows many successful examples.

Building and Distributing a Force.com app

Last month, at Dreamforce 2011, I had the privilege of speaking to an audience of people thinking of building a commercial software product on Force.com. Since my company helps this specific market, I was asked to co-present with someone from Salesforce’s marketing group that supports these people in their efforts.

This article is a summary of the material I presented. Here’s a high-level outline:

  • Building Your Team and Your Knowledge

  • The Build Process: Technical and Licensing Concerns

  • Stories From The Field

  • OK, Let’s Get Started

I represented the perspective of “someone who’s been through it.” To steer clear of legal issues, I’ll omit details of the content presented by the other person. Here’s a simplified version of my slide deck, with an explanatory article below.

Think Different(ly)

I began with a show of hands asking how many folks in the audience had an iPhone or an iPad. Luckily, I had a significant number, so I was able to use my analogy comparing Force.com development to iOS development. Both types introduce significant new elements—new programming languages, APIs, distribution methods and quality processes.

These new elements necessitate a shift in thinking from traditional Java or .NET development—one which starts in design, affects coding and extends into sales. Directly “porting” an existing application concept to Force.com would be no more successful than porting the entirety of Microsoft Excel to the iPhone. There’s a different definition of what makes an app great.

Concrete Examples

Let’s take the example of building a simple blog system that organizes Articles into one or more Categories: Force.com’s object database causes the fundamental data model to include notable differences. The Categories are defined as a first-class attribute of the Article, rather than as a separate table (requiring yet a third junction table). Moreover, this structure allows the system to render an appropriate UI to assign an Article to multiple Categories without any custom code.

Force.com also includes a major difference at the user interface level: a native, out-of-box UI that matches Salesforce’s CRM and Service apps. The interaction and visual design of most Java or .NET apps will start with a blank slate. The default UI may or may not be a great fit for your app, but in either case it’s worth respecting the conventions to which Salesforce users are accustomed. Reducing friction for end users will drive adoption and word-of-mouth referrals.

Look Beyond Development

The Force.com platform is broad and deep; launching an app on Force.com is definitely standing on the shoulders of giants. Hence, it’s possible that the engineering effort to build an app is actually less than you imagine. That said, most folks with a development mindset don’t plan sufficiently for the work to distribute the app. Working through the Security Review process and listing on the App Exchange are activities that require time and planning.

It’s natural to “go with what you know” and focus on simply building the app. Unfortunately, that’s not the finish line. ISVs would be well-served to start planning for non-development activities sooner rather than later.

The Role of the PDO (Product Development Outsourcer)

Salesforce refers to my company as a PDO (Product Development Outsourcer)—we can design an application, handle the development and help a client through the work of launching onto the App Exchange. On the majority of our prior engagements, we’ve done the lion’s share of the development.

Over time, however, the client team ramps up and takes over. As a corporate asset, the app is their intellectual property and it’s critical to assemble a team with the skills necessary to be a successful software company over the long term. This includes not only development, but also related functions like customer support and product management.

Our model is not to become “embedded” as a vendor for many years. In fact, we’re thrilled to hear success stories from former clients who no longer need our “training wheels.”

OK, Let’s Get Started

If you’re an ISV that’s ready and willing to head down this path, how do you begin? It’s actually quite simple: our usual process is to meet with you and have you explain the long-term vision of your application. We need to understand your definition of success. Then, we’ll discuss any tricky requirements in a little more depth, go back to our offices and reflect on everything we’ve learned. Finally, we develop an overall design concept of what it would look like to host your app within Force.com, and we share the concept with you to get feedback.

It’s analogous to meeting with an architect to design a custom home, describing what you need, and seeing an initial sketch. Almost all the elements in the design are still negotiable, but the sketch gives you confidence the architect understands your end goal.

Architectural sketch

Architectural sketch

Most often, our initial sketch takes the form of a concept model. Once you’re comfortable with what you see, we’ll begin a formal planning process and design phase to capture and spec out all the specifics. After the design phase is complete, we scope the actual development work.

If I could choose to have the audience remember only one idea from my presentation, it would be this: prior experience building software will help you succeed on Force.com, but don’t expect to do things the way you’ve always done them. Embrace the change.