Product Development Guide for IoT Product Managers
This fantastic guide will make sure your IoT product gets from prototype to production with as little trouble as possible.
Join the DZone community and get the full member experience.
Join For FreeIn this piece, I will talk about a few nuances of IoT product development and how to de-risk the costs and timeline of your IoT initiative. It would help if you already have product management experience but not a necessity. If you are an entrepreneur or a product manager at an enterprise, this article will help throw in the IoT perspective to the regular product management experience.
I like building things from scratch and I like product management because it’s like nurturing a baby until it can sustain on its own. Every product is different and there are new learnings to draw but there are certain principles that hold true every time. These principles are time-tested pointers drawn from my 15 years of experience that will increase your chances of success in realizing the outcome you seek out of the product being built. Having worked in the IoT space for the last 5 years, I have learned quite a few, relatively newer aspects of product management that are crucial in your IoT product development. IoT is new and complicated. Traditional product management principles still apply but there is much more to be considered when it comes to IoT. Let us talk briefly about the basics of product management and then we will dig into the specifics around product development.
Product management scope
If you are a product manager, you are ultimately responsible for the success of the product. There are no cutting corners here - you own the product and you rest not when the product is delivered but only when the product is successful in the market. The responsibility for success makes product management different from project management and product development. Developing a product may involve more than one team working on different aspects of the product. The simplest t example being a product that involves developing hardware as well as software. There would be different teams working on these two areas led by different project managers. They have their own scope of work, schedule and deliverables but they tie together into the final product. This final product is owned and managed by the product manager. One of the major responsibilities of his or her role is to coordinate among the various project managers to ensure that the product development roadmap is on schedule and on budget. We will cover product development in detail later in this piece.
What Do You Do as a Product Manager?
Market identification and research, Idea refinement, validation and finding the Product-Market Fit: Since a product manager is responsible for the success of the product, finding the product-market fit becomes the most important activity when you start with the initiative. After your market research signals that there is an opportunity for this product, you will have to refine the idea multiple times using Proof of Concept (POC) prototypes and gather actual user feedback through Minimum Viable Product (MVP) prototypes. There is a lot to do to find the product-market fit. Do not spend more resources until you are sure of the product-market fit.
Scoping for work, roadmap schedule, Identifying teams & dependencies and owners: The scope should include technical as well business side of the product. You will have to identify teams for architecture, design, development, testing, support, marketing, certification, security, manufacturing and logistics. One of the major surprises product managers hate is realizing an unforeseen dependency which delays the entire product roadmap. Make sure you look for ongoing dependencies between teams and various deliverables in your weekly tracking meetings. A dependency is something because of which a task is blocked or a resource cannot deliver on his or her commitments.
Find the best team owners: You might have to gather multiple expert teams in categories such as analytics, Web or mobile apps, wireless, hardware design etc. Your task will become much easier if you find capable owners for each of these teams. Give special attention to the hardware team because small mistakes there could prove to be very costly in the future. Make sure you have the hardware owner who is well versed with hardware development life cycle stages - EVT DVT PVT and is reliable.
Go to Market: You should work closely with the marketing team for launch and promotions, and the sales team for distribution and continuous feedback. You would be directly involved in finalizing and executing the go-to-market plan, identifying and correcting the fault lines on a regular basis as the market responds to your marketing and sales efforts.
Product Development
Developing a product takes the majority of the resources and time. The biggest challenge in product development is how to keep up with the planned timeline. Schedule slippage means increased development cost, and a huge opportunity cost because your product will be late to the market. I am sure that you can find a lot of good resources online to guide you about product development but there are some undercurrents that could derail the entire process which no one openly talks about. The tips below will help you get a better grip on the timeline.
Identify existing capabilities and what you can do in-house. Do a build vs buy analysis, and similarly, do an in house vs outsource analysis. Hiring new talent takes time, getting productive takes time, getting into organization culture takes time, and getting teams to work together takes time. Any delay to the market will increase the opportunity costs.
The second biggest area of concern is integration. In big projects, integration is highly challenging. A minor change in one area breaks things in the other. Moreover, experts from different teams speak their own language and the communication gap becomes a huge bottleneck. I use two ways to solve this problem
Clearly define not only deliverables but also interfaces between various components of your product. Ideally have a unified standard for interfaces in the company and use these interfaces for integration. A secured interface should be a key part of the team’s deliverables. This also means that you will have to allocate enough time and thought to define the interfaces when you decide on the architecture.
Keep a dedicated senior technical resource, preferably with an architecture and development background as the integration specialist who works with all the teams involved from the integration perspective all the way along.
Build team chemistry. Have fun while building a performance culture. It is very important that your teams don’t burn out and that they enjoy working with each other. In my experience, personal differences and egos can negatively impact the timeline in ways that you can never pinpoint the exact root cause. This becomes more important if you have teams in different geographies. Having smoother cross-site relationships makes things move much faster. I had a colleague at AMD in Austin, quite senior to me, drive 30mins in the middle of the Friday night while I was working in an AMD office at Bangalore and change a hard drive on one of the emulators. That saved one whole weekend for me.
Product Development for IoT
IoT is new and it is complicated. If you look at even the simplest IoT stack, it is a no brainer that stitching together so many layers into a smoothly operating IoT solution is going to be challenging. You can find good pointers at IoTForAll.com and DanielElizalde.com to guide you through the IoT development process. In my 5 years of experience in engineering IoT products, I have identified the below challenges which when addressed from the beginning can greatly increase chances of success for your IoT initiative.
Do Not Try to Do it all by Yourself:
The biggest challenge I have seen is that IoT talent is in short supply. There needs to be a comprehensive understanding of full-stack IoT development from the very beginning of your project cycle. Unfortunately, you will not find many people who have this understanding even in hi-tech ecosystems such as silicon valley. No one person or company can do everything in IoT - you will have to collaborate. I recommend doing a thorough assessment of what you can do in-house as the first step and then find expert IoT services partners in each of the areas where you lack. As a result of this exercise, you should form a team covering all areas of the IoT stack. This team should be involved in not just the development but also the planning of your entire project because you need to draw from the experiences of experts who have done this in the past. Trust me when I say that IoT is new and the only way to avoid unforeseen delays is to learn from the people who have been there. Most companies run into unforeseen issues and the blame game starts which is highly detrimental to the initiative. I also humbly ask you to avoid hiring all the experts on your rolls and instead focus on your core business - let the development partners do what they are best at because IoT development is costly and often unpredictable.
Find the Right Fit Partner
Should you decide to outsource the whole or parts of the project, finding the right fit partner is a major challenge. I am emphasizing the term “right fit” here because, in 5 years of my IoT custom engineering experience, I have seen it first hand that multiple clients took 3-6 months just to find an engineering partner and many times they burnt their fingers with a wrong partner which meant almost a year in lost market opportunity, not to mention 200-300K USD down the drain in product development. In fact, because we frequently saw these issues, we launched Ioterra - a platform to find product development partners. It is simple logic that if you are building a product for healthcare, then you should prefer a partner who has built such products in the past which will avoid costly mistakes. Think long term when looking for partners - partners may include design partners to custom engineer the product in various disciplines, manufacturing and supply chain partners, system integration partners who deploy and maintain the IoT solution, security experts to audit and optimize your product and the certification partners who help you get your product certified for a specific geography.
Business-focused Decision Making Is Key to Success
The thing with IoT is that while taking product-related decisions, you not only need to consider the technicalities of the technology but also the practicalities of the business you are in. Focusing on the business outcome while making your product decisions will go a long way in ensuring your RoI from the IoT initiative. For example, you have an issue in your operations for which you believe that IoT can give you huge efficiency gains but think twice before you put in time and money in building an IoT solution because the issue could very well be solved with few changes in your process. You must evaluate whether IoT is the right solution to the problem you are facing because IoT is costly and it might take years to realize the intended RoI. Check out this article about when and how to leverage IoT for digital transformation.
Tips for a Successful Development Cycle
Before I wrap up, let me share a quickfire, few rules of the development game drawn from years of experience
Find Devils Advocates for Your Project Plan and Architecture Review
Consult IoT experts who have done it before who can plug holes into your project plan including the development as well as the deployment plan, and the architecture including the technical as well as the security architecture. It is good to identify potential bottlenecks at the beginning rather than running into unforeseen problems later.
The 1-hour Rule
If any of the resources are stuck with a problem for more than 1 hour, he/she should seek help from others to solve the issue otherwise it’s a waste of the company’s time and money. The resource should still own the solving of the problem but the solution will be found way faster and it will be a tremendous learning curve for the resource too.
The Multitasking Rule
Research has proved, and also in my personal experience, that a resource starts getting less productive if you assign more than 2 distinct responsibilities to him/her. Few people can do multi-focusing. You want 100% from each of your resources.
Burn Out and Fun Rule
Do not utilize your resources so intensely that it leads to burnout. Have gaps in between aggressive work schedules for people to have fun and rejuvenate. Take the team out for a party or a fun day outing or even simple team lunches. We are humans and we are more productive when we are having fun doing it.
Red Flag Rule
Raise red flags immediately. I have observed that people shy away from raising red flags. No plan is foolproof. Make sure you track progress weekly and raise a red flag immediately. Once the flag is raised, it is the manager’s responsibility to resolve the issue
Be Skeptical of New Components, Libraries, and APIs
If you are trying out a new API, component or library, be it SW or HW, do not trust the release notes. Usually one tends to search for capabilities and if the new component offers the features you need, you jump on to using it. Instead, focus your research on reliability - try to find the issues with the new stuff you want to try. You will be surprised to discover issues even from those products which were developed by reputed engineering brands.
Best Talent Rule
This goes without saying that people are the foundation for a project’s success. This is most crucial to the timeline of your project because the best people will make things happen. Be it engineers or managers or vendors or marketing resources, a product manager should invest time early on in getting the best talent for the project who has the reputation of meeting commitments on time. And for IoT projects, make sure you have a dedicated resource focused on integration from the very beginning who has prior experience in IoT projects.
Best of luck with your IoT journey.
Opinions expressed by DZone contributors are their own.
Comments