In this blog post, I would like to share some information on a project that I am currently working on, called bRemote (Bee Remote). This project is part of a course I currently attend, called Master Class High-Tech Systems Creations. This Master Class creates a multidisciplinary setting, where it educates in System Architecting, Business Development and Project Management. It is a two-year course with participants of different disciplines namely electronics, software, mechatronics, mechanics and physics. The first year of the course is has a theoretical approach and the second year is practically oriented. The project bRemote, is part of the second year.
The project context
With a group of seven persons, with different backgrounds, we started the project phase by exploring the feasibility of various ideas. Main goals of the project phase are to come up with a business plan and preferably work towards a first stage prototype. During the exploration phase we tried to validate the business cases of different ideas. During marketing research of the first idea (a portable version of the CTG, a medical device for fetal health monitoring), we concluded that the idea had little to no chance of succeeding. However, we gained fast and helpful experience to analyze business cases with use of, among others, the Business Canvas (Osterwalder Model), decision matrix and brain writing. After we dropped the idea for a medical device and some brainstorm sessions later, we pivoted to the idea to improve beekeeping with the help of (Internet-of-Things related) technology. Hence our bRemote project was born.
Contacting and meeting amateur beekeepers was the first step to find out what their main challenges are. We read as much as possible on the internet, but coming in contact with your potential customer is the most important source of information to assess the potential of a business case. After some discussion, we decided to get a second opinion from a professional beekeeper, who became our launching customer. After several meetings and writing down the user requirements, we defined together with the customer the so-called Minimal Viable Product (MVP).
In the project group, we divided roles like Project leader, Marketing & Sales, and System Architect. I opted for the System Architect role, since for me this was the main driver to attend the Master Class High-Tech Systems Creations.
The Minimum Viable Product
The functionality of our MVP, that we aim to make for the professional beekeeper, consists of two major features, namely:
- The ability to remotely measure the activity of the bee colony at the beehive
- The ability to remotely open and close the entrance of the beehive
The primary goal behind the first function is to measure the health of the bee colony. This gives an indication for the beekeeper to notice whether something unusual is happening in or outside the beehive. For instance, we can early on spot the degradation of the monitored colony. By responding quickly, it helps to keep the colony healthy and reduces cost of losing a part or the complete colony. This translates back into increased and sustainable profit for the beekeeper.
The second required function, being able to open and close the beehive remotely, arose when we were talking about common tasks during the bee season. The beekeeper needs to move the beehives to different locations. For this he has to get up before sunrise, close the beehives manually and relocate them. Alternately, he can do this after sunset since all the bees need to be inside. If the beekeeper is able to close the hives remotely, he can move them during normal working hours, which of course is more preferable.
Below you can see a simple diagram of our system that we aim to make.
During the prototyping phase, we came across challenges like energy consumption, since we have limited amount of energy (battery powered). In addition, things like selecting the radio communication technology, choosing the right sensors to detect the bee activity, and designing a robust open and close mechanism, was not straightforward either. In one of my next posts, I will share some more info on the prototyping phase.
What are the important takeaways so far?
Go out to your potential customers as fast as possible. The customer has valuable information that you cannot gather in other ways. No information on the internet replaces the experience gained in practice, in our case the experience of the professional beekeeper.
Learn to fail fast. Since in all creation processes it is inevitable that we make wrong assumptions, and that we need to mitigate risks. Therefore, it is important to fail fast and learn from these experiences to create a better product. For this reason, we defined a Minimum Viable Product and we regularly share and test our progress with our launching customer.
Do not aim to create a product first time right. Most of the products nowadays go through several small iterations before launch. If we would have discussions with the customer only in the beginning of the product development cycle, chances are that the product is not what the customer expected at the moment that it is delivered in the end. That is why we use a scrum-like approach in our project, define a Minimum Viable Product, and try to involve our launching customer as much as possible.
Since the project is continuing, I will keep you posted on our progress and learning process. If after reading this post, you have questions or suggestions please contact me. Also, if you are interested in the project and want to receive updates let me know.
— Bob Peters (Embedded System Engineer), Embedded Systems Enthusiast