Catching Lightning: How to Use Custom Software to Solve Common Business Challenges

Organizations are always looking for what's next, regardless of their size or mission. They want to find that next inflection point – the process, technology, product, service, or skill capable of influencing business outcomes and customer experiences. We’re often asked by customers, “What do I need to do to make my operations better, faster, or more reliable?”

As technology continues to improve, software is consistently one of those inflection points we at Zebra have found to be most impactful. But the challenge for most organizations is identifying the right software opportunities amidst the noise and then understanding how to take advantage of that opportunity for improvement.

For example, one of my customers – a large, successful company considered a leader in its industry – is highly data driven. It is always looking for ways to improve its workflow and data accuracy. One of its senior product managers approached me after struggling with how to smooth out an onboarding problem. It was expanding its business and running into pain points. One day, an idea struck him: "what if we move one of our set up processes to the upstream vendors? We could provide them with a custom application that would streamline a key pain point.” He knew if he could build that application, it would allow his company to expand its operations faster.

The challenge then became:

• defining his idea so he could communicate it to his stakeholders.
• visualizing his idea so everyone could move in the same direction.
• getting buy in on the project requirements.
• developing the application.
• validating the application was solving the opportunity he had seen.
• deploying the solution to his suppliers.

These milestones are common for custom software deployments. So, these are the considerations I shared with him that will be applicable for your next project:

Step One: Know What to Look for When Searching for a Software-Centric Inflection Point

The first challenge is identifying an opportunity of value. Is it narrow enough to act on? Is it something you have control or influence over? The ideal is to find a targeted area that you can limit the scope to the core of what will provide value. It may seem like the more open field and limitless the easier it will be to execute, but the opposite is usually true. The more we can constrain and focus the effort, the quicker we can execute and the greater our chance of success.  

Step Two: Determine How Best to Define Your Idea

A guiding belief of mine is that people find things easier to understand once they can see them in a tangible way. It also becomes easier to make decisions about their viability or usefulness. With that, I’ve found the best way to define an idea is by using design thinking, a framework created by the design firm IDEO. It has since grown and is being used globally by many organizations ranging from small design teams to large companies like IBM and Google.

There are five core phases to design thinking:

1. Empathize with your users.
2. Define your users’ needs and problems and your insights.
3. Ideate by challenging assumptions and creating ideas for innovative solutions.
4. Prototype to start creating solutions.
5. Test solutions.

The core idea isn't to become an expert in design thinking, but to use the principles to help visualize your idea. Use the framework to identify the value proposition. Then create a prototype which will align your stakeholders and get feedback from the end users.  

Step Three: Specify What the Development Team Should Do?

Once you have identified and created your prototype, the next step is to translate that vision to a development team to build. There are many tools available to help translate the idea into an engineer's language. In general, most teams are using some form of agile development. Agile revolves around the idea of working in sprints. A sprint is usually two weeks, and then you iterate after each sprint. Most teams are using some flavor of agile they have adjusted to meet their needs. My team found using a hybrid approach works best for us. We use a waterfall-esque process for requirement gathering and then rely on agile structures to execute the requirements.

There are also a few other elements to focus on during development:

• Use a design tool to translate the designs into usable elements such as Figma, Invision, or Zeplin.
• Leverage a story tracking tool like Jira or Microsoft DevOps to track and manage your work items.
• Using a cloud repository like GitHub, Gitlab, Bitbucket or Azure DevOps to store the project code.
• Have an automated build pipeline and integrated test plan.

All these components can help reduce risk while building the idea. Development should also have regular check-ins to keep the vision on track. As the vision is getting closer, it's also important to plan for testing and validating.

Step Four: Validate and Test

We've found the earlier you can start thinking about testing, the smoother the testing will go. Plan to work on a test plan while the engineers are building the application. A good test plan should be written with individual test cases that can be explained and executed on their own. The goal of a test plan is to build your bridge to releasing. The first impression your users have of the application is hard to change. A solid test plan helps make it a positive impression. So, confirm the areas in which users will be spending time, then ensure the test plan has a net built in to catch issues and defects before the application gets into users' hands.

Once you have written and built the test plan, the next step is to define how you will execute it. Do you need specific devices? Will testers need access to any restricted networks? Is there enough test data to support executing the entire test plan?

We've seen teams struggle often with having test data available. It's easy to use up test data while running the plan and having a method to refresh your test data is vital for success. What should be a straight-forward execution plan can get lost in the mire of running out of test data. While your development team is busy, start lining up how you'll test and how long you'll need to validate the application. If you do, your stakeholders will thank you. Once you have a successful validation phase behind you, you can then focus on deploying and supporting the application.

Step Five: Deploy and Support

Before you can deploy the application, you'll need to map out how to get the application into your users' hands. What mobile device management (MDM) solution are you using? Will the devices need a specific configuration? Will the users require additional training? Are there any timing issues? What's the support plan for addressing issues that come up once the application hits use at scale?

Deploying an application can sometimes be as simple as loading it onto a few devices. Or it can be as complicated as staging a multi-wave rollout across hundreds of sites. Just know that once any application hits scale, issues will crop up. No team, no matter how skilled or prepared, will catch every use case in the testing and validation phases. Something will always slip through the cracks.

It's important to acknowledge that early and plan for issue resolution – even if you don’t quite know what precise resources will be needed. Have your team ready to support rollout for an extended period of time. Plan for restaging and deploying point releases to address issues. Work to control expectations and align the stakeholder team with the realities of deployment. Many common project issues can be avoided before they turn into escalations.

Step Six: Bring it Home

It’s hard to know what “success” looks like if it isn’t clearly defined from day one and, unfortunately, this is a key contributor to success in and of itself. Don’t let it get lost along the way. What are the key performance indicators (KPI)? What return or improvement will be a win for the business? Agree upon your definition of success at the start and then validate each decision against it. This will ensure you are communicating effectively through each phase and help the team make decisions around what work to take on and what to backlog.

The customer I mentioned before actually found this single action was the cornerstone for bringing his custom software idea to fruition. He narrowed down his scope and definition of success. He joined the daily stand-ups to help keep the vision aligned and keep focusing on what success looked like. He regularly talked through what success metrics he needed. He developed the test plan, making sure it was solid and the data was there. When development ended, the moment of truth came. How would the application perform at scale, and was his insight correct?

Spoiler alert: it was a wild success! The application was stable even after millions of item scans. The focus, while narrow, resulted in saving thousands of labor hours per year. The best part? It helped the business expand.

One of my favorite aspects of seeing so many interesting ideas is that one good idea usually unlocks the potential for more ideas that can be built upon it. In this case, the results both proved the value of a key insight and opened ongoing projects that continue the path forward. And that allows for the company to recognize and take advantage of new inflection points.

Hesitant to Run with An Idea?

At the end of the day, remember that anyone can come up with a critical insight. While it might seem daunting, keep your focus narrow and targeted. Don't try to build the “be all and end all" software solution. Focus on solving one problem at a time. Use the tools available to you: design thinking, agile, and test-driven development. There is no end to the tools available, but they are just that… "tools." A tool is only as valuable as the ability of the person wielding it. Choose something in your skillset and leverage it. And always keep your eye on what success looks like. 

Of course, if you want to bounce your ideas off someone else, you can always contact me and my team. 

###

Editor's Note