Research and Development Deliverables

Photo by Helloquence on Unsplash

Crux = the decisive or most important point at issue

Every custom software project has a crux. This isn’t caused by a lack of experience, as much as by complexity and unknowns inherent in software development. By definition, when building custom software, you are building something that has never been built before.

At Polar Notion, when we discuss potential projects, we want to identify this crux and work through it early. That helps us know the best course of action to maximize value for the client. Typically, we’ll stick with our tried and true process, and account for the crux along the way.

However, sometimes we recognize the crux is so massive, we decide to tackle it first through an Research and Development Sprint. This is usually because of one of these reasons (or both)

1. Major uncertainty — “nobody has even done anything like this before!”
2. All the value of the software is tied to the crux — “if the software can’t do X, it’s not worth building at all!”

One example would be a photo uploading interface. We started that project with an R&D Sprint to confirm the photo upload capabilities, before moving on to design and develop supplemental features. Without getting the crux right, the interface had little value. In the end, we had more clarity about the limitations and ultimately shifted our approach based on our learnings.

Our R&D Sprints are typically 1–2 weeks long. We start with research, followed by planning and executing a series of tests. We learn from each test and try to iterate our way to a solution. The goal is first and foremost to learn. That being said, we often do end up with something functional at the end.

Here are the three potential outcomes of the R&D Sprint.

1. Functional product/prototype — It won’t be polished, but we proved definitively we can build a software that does what you’re looking for.
2. Clearer understanding — we won’t always arrive at something functional. Perhaps we uncovered additional complexity or the time allotted wasn’t enough to get us there. In this case, we’d have a better understanding of the effort required to get to a functional product and the nature of the problems we’re trying to solve.
3. Shut it down — We learn that what you’re wanting to build isn’t (realistically) possible. Obviously, this is the least desirable result. If possible, we want to catch this before we start, but sometimes it takes diving in and testing things out to learn realistic limitations. On the bright side, learning this early in the process might have just saved you tens or hundreds of thousands of dollars of development costs.

Even though option 1 is the desired outcome, each of those outcomes provides significant value. The learning that comes along with the R&D process often provides clarity and confidence to move forward, or wisely shut it down.

Polar Notion is a software agency based in Atlanta, GA. We solve real-world problems through digital solutions. If you think we may be able to help you or your organization, please reach out to walker@polarnotion.com.