Skip to main content

Finding your product at balena

Each of the described characteristics serves as a signal to help define and identify products. Depending on the level of maturity, not all products will have all characteristics at all times. For example, it may not make sense to start to try to build a community for some products when it’s still in the idea phase, but for others it might (it works for Kickstarter projects!). It may not make sense to start all products with a brand and a logo, but it should at least make sense to add one at some point. A product should lend itself to having each of these characteristics at some point in time; if they don’t fit or don’t make sense it should be used as a signal that the current form is not yet a product and requires more thought.

When it comes to finding your product at balena, we’re all working towards a shared mission: to unlock the potential of physical computing by reducing friction for fleet owners. In that regard, everything we build should in some way be in pursuit of the balena mission. There are varying degrees of pursuit, meaning that some products align more literally and directly with the mission than others that may help in a more indirect and abstract manner.

For example​

Directly helping the mission​

Etcher Pro: The ability to flash 16 SD cards at once reduces friction for fleet owners.

Indirectly helping the mission​

The Services Model: Helps us reduce our spend on unnecessary / expensive services, so that we don't run out of money and become unable to help reduce friction for fleet owners.

Creating a new product (Greenfield)​

Creating a new product from scratch involves developing it to the point where a loop is created and the idea can be iterated upon. This means:

  • Identifying the need for a product - sensing and patterns can feed into this. If it's a feature that doesn't fit within an existing product, does it require a new one?
  • Ideation stage (design thinking)
  • Prototyping, testing, hypothesis
  • Establishing the loop around the product in order to start iterating - sensing, patterns, improvements, development, releases etc.
  • Reaching steady state/MVP

Reviving, renovating or continuing development of an existing product (Brownfield)​

  • Isolating it out of the chaos, “de-hairballing”
  • Pulling apart, extracting modules, defining interfaces (applying product definition)
  • Repairing or improving its loop
  • Picking up, becoming the custodian

Products today and tomorrow​

Just because something isn’t a product today, that doesn’t mean it can’t be one tomorrow. Products are about architecture and packaging as much as they are functionality. Let’s consider the balena builder; we use it as part of balenaCloud to build container images for devices. It’s not a product as it’s deeply tied into our use case. But, are there users out there that would also like to build container images for devices outside of the balena context? Of course! So, why wouldn’t we package our builder functionality so that others can use it in their product in the same way we use it in ours, and make it valuable standalone?