Have you ever noticed a common theme among the first episodes of most tv shows?

The word pilot perhaps?

This is because the first episode of a television series is broadcast as a test for the network to see if it will be a success. This might sound a little drastic, and you are probably wondering why the success of a show can come down to that crucial point.

Drastic? Yes. Common? Absolutely!

So common in fact that this is something we do in the software industry, with our own spin on it of course. You see, piloting (or testing) is a fantastic way to understand the true nature of your consumers and their experience.

It might sound like all the success rides on this single moment in time, but truth be told, there are many mechanisms we can put in place to ensure that pilot moment is a success, or at least as successful as it can be.

To understand how these mechanisms can moderate the relationship between product success and customer success, have a look at the diagram below:

In this relationship diagram, I have positioned product success and customer success on the same continuum where they are feeding information back to each other and other areas of the organisation. I have done this because when one does well, the other follows closely, in an incredibly careful balancing act.

It is also important to note that product success is moderated and influenced by other organisational influences such as:

• Marketing
• Sales
• Development
• Operations

Just to clarify, a moderating factor (or variable) influences the strength to which a relationship.) is found.

For example, the relationship between product success and customer success can be moderated by the kinds of customers the marketing team attracts to the product. For instance, the ideal customer will (hopefully) strengthen the relationship between product and customer successes. Whereas a detracting customer will weaken this relationship.

Needless to say, our success, product, sales, marketing, development, and operations teams have a tight knit relationship!

However, this article is not solely about this relationship, as I want to focus on its origins.

Before we launch to customers, through a pilot(!), there are elements of the product that need to be successful first. These are:

• Performance
• Problem solving
• Seamless integrations

Performance

An application needs to perform technically, visually, and efficiently.

Firstly, technical performance (at a high level) is the degree to which the application sends and receives requests to and from the servers and users, this sits with the development team. Next, the visual performance refers how the product is designed and what aspects of it the user can see, this sits with the UI/UX team. Finally, the efficiency of the application refers to the behaviours needed to complete the workflow/s within the application.

I have only just scratched the surface of performance here but there are many facets within each of the 3 layers of performance that are required to ensure the successful performance of an application.

Problem Solving

This might seem odd, but when you think about it, an application is designed to solve a problem. “There’s an app for that” aptly demonstrates that no matter the problem, there is an app to solve it.

So, why are we still building them??? Well, that comes down to how well that problem is solved by the existing applications in market, or maybe that solution is so complex, the application has not been built yet!

So, to reiterate the point, the reason why a user would use an app is to solve a problem. I have an app for my alarm clock so that I don’t sleep in, a photo library app so that I can store my memories, a running app so that I can track my runs…nearly every part of my life has an application attached to it.

This is not meant to sound horrifying; it is merely a reflection of the technologically centred lives we have today. So, instead of running for the hills and switching off – embrace it!

Applications that are successful products demonstrate their problem-solving capabilities over and above their competition. In my previous blog, I unpacked the issues I experienced with my past banking app that, if I look at it from a problem-solving point of view, could not solve the critical problems a banking app is intended to solve (i.e., transfers, repayments, spend tracking, etc.) which is why I switched apps.

Seamless Integrations

The whole point of a native app is that it works seamlessly into the users’ device usage.

To investigate this a bit further, I am going to go back to the alarm clock reference. Using my phone as my alarm clock (as so many other people do), feeds data into other areas of my phone that assist me with using the device.

For example, as my alarm clock is set to the same time each weekday, my notifications settings (are allowed) to adapt to this seamlessly.

Of course, there are settings that allow users to self-select this data sharing, but to be honest, I like the automation!

Another example can be simply shown in iCloud! I love the fact that I have iCloud on my phone, iPad and MacBook because everything just works together so seamlessly.

Another way to look at it is switching between a desktop/web application to a native mobile application. For example, I can open the Outlook desktop app, the web app and the mobile app and should see the same data (i.e. emails) displaying in the same folders. This is an example of data synchronisation, but it is a big part of the seamless integration layer of product success.

It goes without saying, these layers need to be optimally operating to ensure the overall success of the product.

Where to now?

We need to put together an actionable strategic plan that outlines how we are going to make a successful product into a customer success. This is not necessarily a natural thing. You might have all the elements of a successful product, but without the strategy to translate that product into success for your customers, the product won’t continue to be a success.

Step 1: Clearly define the problem that you are trying to solve (which all those moderating business functions can relate to)

At WorkingMouse we stress the need to define the problem clearly from the get-go. To make sure that all business levels are aligned and focused on achieving the same solution. This can also be referred to as a single metric, or the vision of the product.

Setting a strategic single metric for each product and aligning this across the organisation means that there is an agreed objective for the product and each function of the business can work within their teams to achieve this. This allows each department to set their own KPIs that lead to that overarching metric without feeling constrained to the product itself.

Customer Success uses the single metric to map out how each customer using the application will achieve this, and in turn find value in the app.

Step 2: Pilot, test, trial...however you want to put it - just do it!!!

Remember how we said at the beginning that each television program has a first episode that is generally a pilot? This is exactly why!! We have a new product/program/application, and we need to know, even after all of the R&D work we have done, if it is something that the wider audience will want and use (better yet, pay for!).

In launching a pilot of an application there are some non-negotiables that need to be in place before hitting the big red [LAUNCH] button:

Analytics

• (What?!? Again!?!) I know, I know…I say it every time, but it is one of the most, if not the most, important inclusions to ensure is live and recording during your pilot phase
• There are going to be so many opportunities during this pilot to learn from your users, opportunities that you might not come across again
• Coordinate quantitative with qualitative data to paint the overall picture of how your users are feeling

Create a feedback loop

• Feedback can come in many different shapes and sizes – it is crucial to the success of your product and customers to open those avenues up for all to access
• It can fuel priorities, allude to issues you were not aware of, but it can also validate your assumptions about the product and the end-users
• Feedback needs to be accessed internally and externally; remember those organisation functions? They need to be able to see what feedback trends are coming through so they can act on it. The product is not the only thing that can improve from feedback. Think about this, as a product, the feedback is positive, but as a website that details the product and its offering, it might not be as strong. This is great feedback for your marketing team. Those contributing functions will continue to enhance the product’s success.

Demonstrate customer value

• This is a tricky one, but done well, you can reap many benefits
• Testing out a product for the first time can be daunting to many users so you need to show them that you value their time and their efforts
• This could be through monetary incentives, exclusive access to product elements, anything! If it’s something that says, “hey, we appreciate you, thank you for spending the time to do this,” that might be just enough to demonstrate back to your customers that you value them.

Step 3: Analyse, Evaluate and Iterate!

You have all this data, all this feedback and a happy pilot testing base, now what?

Analyse the feedback and data you have received

Ask yourself (n.b this is not an exhaustive list):

• Are there particular themes highlighted?
• Is one section or multiple sections of the app commented on?
• What were the pain points?
• What were the success points?
• And did the users solve the problem the app aimed to solve?

Evaluate the responsibilities of the feedback

Once the analytics and feedback has been analysed and sorted, it is time to evaluate who, or which department rather, does the responsibility of actioning this feedback lie with?

For example, if the app is slow to respond, this would be something the development team would need to be aware of.

It is critical that during the evaluation, the feedback points need to be considered and as helpful or hindering. What I mean here is that sometimes applications can be victim to designing iterations from feedback, instead of sticking to their guns and just being influenced by feedback.

Iterate from evaluations

Using the evaluated feedback points, the application will need to be iterated repeatedly. Iterations are not meant to be considered as “rebuilds” they are more like continuous improvements and consolidations of solving the initial problem.

Just from the length of this article we can see that there is quite a lot that goes into the ensuring a product is set up for success to then lead its customers to success.

If we go back to the original relationship diagram and making note of the bilateral direction the arrows depict between product success and customer success. Setting up a product for success is just the beginning of the relationship between product and customer success.

It is safe to conclude that product success and customer success should continue to work with each other to deliver a successful application to the users.

Remember, we are always here to help – so reach out and book a strategy session with us!