.svg "InOrbit"){kind=logo}
The value of early feedback in any product development – including software – is, well, invaluable.
Software development has evolved over the last 20 years to allow for more incremental or iterative development, to help eliminate the problems of delivering a product that a customer doesn’t want. We all know software engineers who have suffered from spending monumental time and effort on creating something that ends up being the wrong product, tool or app.
Maybe the product is not timely anymore. Or more likely, assumptions made (“requirements”, user stories, design decisions, etc.) diverge from the real-life scenario. Both problems can in one way or the other be amplified while the product takes shape. This happens if developers do not take the time to validate and refine assumptions, making room for adjustments in the development process. Or more drastically, for extreme direction changes: canceling a project altogether.
The InOrbit team ensures we are iterative whenever we develop a new feature or function for the platform. This includes recent improvements such as Time Capsule or The Developer Portal.
An Investment
We believe that effective RobOps are needed Moreover they will be needed more as robot manufacturers grow and robot deployments become more pervasive in everyday life. Robotic fleets will only expand to become more diverse and heterogeneous.
But RobOps as a term did not exist even five years ago while InOrbit was being formed. So how did we get here? The truth is, robot manufacturers have been encountering the same pain points again and again as automation starts to move from controlled pilots to scaled realities. Strong RobOps means effective software solutions, but it also means interoperability, safety, harmony with humans in the real world, reliable incident management, a host of best practices, and useful analytics that can drive businesses forward on their robotics journey. These are concepts that require focused attention and dedicated investments. Robot manufacturers don’t have infinite time or resources to build the necessary supportive infrastructure that scaled operations require. Developing often complex tools to effectively solve robotics challenges requires a new approach.
Experiments
A particularly useful tool when developing a product is experimentation. The scientific method involves formulating a hypothesis, then testing that hypothesis through controlled experimentation, measuring results, analyzing the data, and drawing validated conclusions. Once insights have been gathered, refinements can be made and iterations of the experiment, or software in our case, can be implemented. When contextualized around a product or service this may sound expensive, but consider how much money a company could spend to build the most elegant, beautiful and feature-rich product – that solves the wrong problem.
Building on those theories the authors Daniel Kahneman and Amos Tversky wrote about dividing yourself into two entities - the “operator” that operates on a regular basis, and the “scientist” that examines the experiment and sees whether the hypothesis has worked. This concept can be expanded to humans, companies, and even software work, where the “scientist” is evaluating the work of an “operator” to see whether a software project is going as planned.
The InOrbit approach
Our process of software development follows a methodical scientific approach and incorporates the heuristic checks and balances required for rigorous validation. As a user and product-centric company, we start with the need. What problem or gap in the platform, software, or tools that we provide do we have a need and opportunity to enhance today? We build much of our workflow around small, short Epic (or projects) with highly focused teams. This allows for a streamlined process and truly agile development. We may scope and design a feature conceptually, interview our user base on its significance and impact on their work with InOrbit, and mock-up roughs in a single development cycle. We may store, postpone, even cancel, or of course, graduate our experiments into full features or updates based on repetitive and conclusive insights. Quick work, and constant evaluation by the team and unbiased observers allow for rapid iteration, refined features, and much more robust end results. As a data-driven company we also continually reassess products and features already launched for ongoing viability and usefulness.
We understand that design and development are living concepts that ebb and flow as a platform and its users, or the industry as a whole, continuously evolve. Experiment-led development keeps InOrbit products nimble and accessible to the concerns of the industry today. This may be felt most significantly in our integrated approach to RobOps support.
A feature-packed 2021
Using this experiment-led approach we “graduated” several features that our customers are using today.
One example is one of our newest releases: Time Capsule, a tool to help users understand what happened to your robots in the past -- perhaps around an incident or while running a mission. InOrbit users can now gain valuable insights on what went wrong with a robot or simply understand how to keep improving their processes. We started this idea as a simple sketch, evolving into wireframes used to conduct several interviews with experts in the field -- both customers, and non-customers. This then turned into an early, experimental implementation in one of our “sandboxes”, separated from the main platform. Having a few users trying it, we collected more feedback about its value, refining our idea of the problem we thought we were solving and our approach for the proposed tool to solve it. Once its value was proven, this turned into a core feature of our platform.
We also launched the InOrbit Developer Portal which includes APIs for programmatic access to your robots and data or to support interoperability with other systems. This significant piece of work is a result of starting with an idea, releasing incremental improvements to our APIs, and validating usage with customers. These iterations started two years ago (the world was so different back then), and continued until we proved our hypothesis that giving programmatic access to robots’ data and being able to provide 2-way communication with robots from whatever environment a robot developer, vendor or integration uses is essential to build a strong platform.
The list of features developed through experimentation goes on… While Time Capsule and our APIs are features that have already “graduated” into our platform, we do not consider them “finished”. The experiment continues and these features will continue to evolve. Others are still in the early stages and being previewed by a small group of users.
Where to next?
Most of the features we’ve recently developed for InOrbit have something in common – they all started as experiments. We brainstormed, developed an idea, and formulated hypotheses. We then created an environment to validate those ideas. Most of these features weren’t actually conceived in 2021; they were all incubated with our customers through UX designs, and in some cases, they grew into features that were tested and iterated upon live in our product.
In this way, InOrbit itself is evolving, through our customers' input. We’ve all experienced seeing a new feature when using an app. When you see it, from InOrbit, you know it’s already gone through more than one validation cycle, including actual usage through our Early Access Programs where some of our customers have gained access to the newest features while still in development, and provided the feedback we rely on. Drop us a line if you're interested in participating in EAPs.
Working at InOrbit is interesting for many reasons. One of the most important aspects is that we are always working on something new. Sometimes we find ourselves doing the wrong thing and discarding it, which is still right. Working here we get used to never finishing anything: Our products and platform are ever-evolving, and we’ve learned to direct our efforts towards focused and iterative experiment-led development.
It’s a pretty exciting time at InOrbit, and we can’t wait to see what the next experiment may reveal.