In the past, working with an IoT product development firm often meant simply handing off a set of requirements and then meeting up to review the results. Yet today, engineers and industrial designers are increasingly working together in a collaborative partnership that involves an ongoing exchange of ideas coming from both sides of the relationship. At the same time, there are some aspects of the IoT product development process that remain the same — as do certain keys to success.
Here are seven tips for maximizing the probability of getting exactly what you want and expect from your IoT product development service provider, whether you’re focused on execution-oriented projects or research-focused initiatives — both of which require boundaries and definitions of success for both the client and service provider.
Seems simple, right? Yet you’d be surprised how rare it is for an IoT product development partner to start with clarity around all expressed and implied expectations. Whenever you engage with a product development consulting firm, it’s crucial to be able to clearly define the goals of the engagement — even when the project is open-ended and research-oriented. Regardless of the type of project, it’s essential to establish parameters for expectations.
It is surprising how often IoT product development experts are called into meetings with prospective clients where the product development requirements are very loosely defined. In these situations, an experienced product development partner will encourage the client to complete a brief and inexpensive “discovery” phase to gather requirements as a baseline. With clearly defined requirements, the client is in a better position to seek competitive proposals and can be confident they are getting apples-to-apples responses.
IoT technologies require a very wide range of skills and expertise to execute a product vision. Be clear in understanding what capabilities you need in your IoT product development partner. Perhaps your core competency is in the back-end infrastructure, analytics and mobile app development. If so, and you are going to outsource the rest to a partner, be sure they have all the expertise and experience in microprocessors, energy management, RF or wired communications, sensing technology, mechanical design and hardware industrial design. A partner with all these skills “in house” under one roof will be more accountable and better able to seamlessly execute the vision than a firm needing to assemble a team from several subcontractors. Team arrangements like this frequently have problems “herding cats” from several partners, each with potentially conflicting cultures and corporate missions. It goes without saying that you want to ensure your product development partner has sufficient bandwidth to handle a project of your scope and complexity. You also want to know, specifically, who from your partner will be the key team members on your program. Watch out for the bait-and-switch where you meet several individuals you expect to be on the team then find out the assigned team members are not the people you expected.
Nearly as dangerous as sketchy requirements are loosely defined deliverables. Having a clearly defined and common understanding of deliverables is not just a measure to satisfy procurement teams; as a purchaser of product development services, it’s necessary in order to understand how your partner will demonstrate results.
It used to be that the client was the one handing off requirements to the IoT product development firm, and the product developers were the only ideators on the project. That’s no longer the case.
Today, engineers and industrial designers are often working in a more agile way, constantly exchanging ideas and fine-tuning plans and concepts based on feedback and new information that’s constantly coming in from a variety of sources. As a client, it’s your right and in your best interest to participate in the process as much as possible. Be sure to establish this as an expectation at the outset of the relationship to ensure you’re working with a firm that values and welcomes your input. Your partner also needs to build collaboration into their project management planning.
Misalignment over acceptance criteria is another potential IoT product development pitfall. Are the quality expectations well understood by both sides? When someone says they are delivering sketches, do you have rough hand-drawn pictures in mind, or are you thinking nicely rendered computer-generated images? Is a proof-of-concept model a prototype that demonstrates the functional properties of the idea — without regard for aesthetics — or are you imagining a fully functional prototype with appealing aesthetics? In particular, definitions around what prototype, documentation standards and so forth are points needing attention to align expectations. Be very careful about the unexpressed but implied expectations. Get these nailed down early and with clarity.
Clarify your expectations on this point at the outset and you’ll avoid huge disparities in terms of cost and time, not to mention lots of dissatisfaction on both sides. Reach agreement up front as to what the service provider must demonstrate in order for work to be accepted.
Surprisingly, this is often an issue. It’s common to break larger programs into phases. Often, the final phase (or even interim phase) payments are contingent on the work in the phase being “complete.” Yet both the buyer and the service provider must have a common definition of what complete means. A final review meeting that allows time for going over all deliverables, followed by a formal acceptance on the part of the client, is a good way to reach consensus on the completion of a phase.
From a service provider’s viewpoint, this is when they can safely provide a final phase invoice. From a client standpoint, the review summarizes each phase and provides confidence that all the commitments have been satisfied.
If you’ve taken into account the items above, then you’ll be ready to hold your service partner accountable for meeting their commitments. With a clear definition of requirements and acceptance criteria, you have a rationale upon which to accept or reject the work of your product development partner. Follow the old axiom, “Say what you will do, then do what you say.”
The biggest issue for anyone as a purchaser of professional services is a misunderstanding of what you expect versus what your service provider has committed to providing. It’s in everyone’s best interest, especially in first engagements, to do as much as possible to clearly and completely articulate expectations before starting the project. By following these tips, you’ll put yourself in a strong position for successful IoT product development partnership — and the creation of a successful IoT product.
Nearly two years have transpired, and while the old tips are still relevant, here are four more insights on the topic gained from our years of experience designing IoT products.