Top Four Tips for Successful Software Pilots

As part of the tech boom over the last few years, a slew of exciting SaaS and enterprise software solutions have exploded into the market. Businesses large and small are racing to bring on new software and partners that can help their employees and workflow processes in all areas of the organization. By 2015, in fact, Gartner predicts that SaaS revenue worldwide will reach in excess of $22 billion.

While new software and platforms can bring great success and efficiency in the long term, they can also bring a lot headaches in the short term. Evaluating new programs and implementing them is hard to execute successfully. At Inkling, we often try to get ahead of these challenges by starting with a software pilot program before targeting mass adoptions across the client organization. This not only allows our clients to test out our software on a smaller audience, but it also gives us the opportunity to learn more about our core users and iterate quickly on our product to better serve those users.

Pilots have been an effective way for us to understand our users better and build trust with our clients. Here are a few hard-won tips that will make any pilot and new software on-boarding process much more successful.

1.  Understand If We’re Addressing Pain Points

At Inkling, we start every pilot with customer discovery interviews to identify pain points with the user’s workflow and current products. We dig deep to make sure we’re solving real problems, that what we offer is a “must-have,” not a “nice-to-have.” For example, one client told us we were a luxury item, like trying to compare a “Mercedes to their existing Civic.” This revelation raised a flag that we were potentially trying to tackle a problem that might already be 80% solved.

In our discovery process, our user experience team engages with two key groups on the client’s side: those who have purview over or exposure to the process of creating and disseminating content and those who are end users of the content (more on the latter in Point #2). We ask open-ended questions to learn about their current habits and seek to validate or invalidate a set of hypotheses about the content collaboration and distribution process. Ideally, we also try to shadow them in their day-to-day operations if we can. By putting ourselves in each person’s shoes, we get to see what truly works and doesn’t work for them.

By understanding a client’s context and the real frustrations they face, we can craft more holistic solutions. Often a client might start by saying, “we want X product or feature.” When we dig deeper, however, sometimes we’ll realize that, while the client is asking for X, what they really need is a solution to a specific problem, which might be better solved by Y. Identifying this early on the process can help both of us tailor the pilot to test out the client’s hypotheses and address true problems, rather than chase down features.

2. Know Your Users

This seems obvious, but identifying all the stakeholders who will be touched by the pilot program is key. Who are the decision makers and who will use your products? Generally, the decision makers will be different from the product users, and there may even be multiple groups of product users.

To use ourselves as an example, we know that our cloud publishing platform has two types of users: content creators and content consumers. Content creators care about how easily they can create fresh new content for digital distribution and collaborate with others to edit and review the content. Content consumers, on the other hand, care about how easily they can access the content and find the information they need. For us, a successful pilot should include both types of users to some degree.

In addition to identifying all types of users, knowing which user types matters the most can make a huge difference in pilot success. For example, in one pilot, it turned out the success criteria was all about the content consumer’s experience, so much so that the content creators were willing to sacrifice their own needs in order to have a better content consumer experience. Therefore, for that pilot to be successful, we needed to prioritize solving the content consumers’ pain points first.

3. Map Out an End-to-End Solution

Even though a pilot is often considered a prototyping phase, both parties must still figure out how to deliver an end-to-end solution. Critically, this doesn’t mean your product has to solve every problem; rather, the client needs to understand how their entire workflow will be impacted.

For Inkling, this means showing the entire content process from how person #1 creates the content in Habitat to how person #2 edits the content to how person #3 publishes the content to how person #4 reads the content. Whatever problem the pilot is tackling, though, without an end-to-end flow, the client has a hard time grasping the whole picture.

4. Iterate, Iterate, Iterate!

The purpose of a pilot program is to test your product solution with a small representative group and iterate on it as quickly as possible. This means identifying a group of users early and giving them the minimal training necessary to start using the product. Your goal is to watch them use your product and get feedback. Don’t sweat the small stuff. While large groups can be unforgiving, pilot users are usually willing to cut you some slack.

For Inkling, this means two things. First, get users into Habitat as quickly as possible so they can start creating content. We move fast on setting up design templates and providing training to our Habitat users. Second, get content to end users so they can evaluate the efficacy of the reading platform. Once content creators are set up in Habitat, we encourage them to publish their first piece of content within a few weeks, so we can get started on the “iterate” part of the pilot as quickly as possible.

We also work with our pilot sponsors to identify a test group that is representative of the overall audience, so we can iterate on every step of the process, with all user types. It is 100 times more effective to hear feedback from an actual end user than from a secondary source, even if he/she might be the main project sponsor.

These are just a few of the top lessons we’ve learned along the way. What other tips have you found to be successful when evaluating and working with new software partners? Let us know in the Comments below!

To learn more about how Inkling works with our customers on these issues and many more, check out our Solutions page.