Developing a product and getting it out there to build a business is really hard. Whether it’s a single person acting alone to push their passion to the public, or a giant corporation with vast resources, everyone has to go through the same basic steps, and everyone needs to screw those steps up in the same way.
The reality is that the whole process needs to involve lots of aspects in order to succeed; small teams fail by not considering or dedicating resources to all of those aspects, and large teams fail by not having enough communication between the teams working on those pieces. But in truth, it’s a balance of many aspects that unlock a chance at a successful product. It’s worth recognizing this balance and seeking it out in your own product development efforts, whether you’re a one-engineer juggernaut or a large, established company.
Getting Buy-InAt home we come up with an idea, we go into our lab/office/bedroom/garage, and we build it. There’s usually not much more than that, except documenting it on Hackaday.io. Product development, however, requires so much more.
The product itself is just a small part of the system. There’s also the manufacturing of the product at scale, packaging, fulfillment, customer support, marketing, sales, and regulatory. In a large company, each of these aspects is a person or a team and their representation and input and effort is required. If any of these teams fail, the product will fail. It’s comforting to know that there is a person who represents each aspect of the product and accepts responsibility and spearheads the labor involved. For a solo entrepreneur, however, this doesn’t exist; they must consider each aspect on their own, and failure to execute on all of them will still result in the entire product failing. Consider all the startups that had great product but couldn’t figure out how to manufacture it at scale, or who faded away into non-existence because they didn’t have a marketing engine. One of the greatest challenges to small startups is executing on all of the aspects of the product, not just the thing itself.
For the solo entrepreneur, their advantage is speed of execution and decision-making. A larger team requires much more coordination and consensus and a single part of it can delay or kill the project. It is the cruise ship with a large staff that handles everything, but takes time to get started and change direction. The solo entrepreneur is a small sailboat, on which they have full control to change direction and execute a quickly hatched plan, but they can’t move as much freight and they can’t cook and tack at the same time.
The similarities between both extremes are where both can improve; in order for a project to succeed, decisions must be made quickly and those decisions must have representation and agreement from all aspects of the project. For the team that means regular cross-team meetings with autonomy to make decisions and adapt to changing conditions. For the solo entrepreneur that means getting out of the comfort shell to work on not just the product, but to actively take the perspective of the business and make decisions based on those perspectives as well.
Constraints That Fight Feature CreepWe all know about feature creep; it’s insidious and fun, because we all love making our products better and more useful. In theory that’s great; in reality it often delays the project, makes it more difficult to manufacture, confuses users, and makes compromises to the original purpose. This is where constraints are the most valuable tool in fighting feature creep. They are fantastic at limiting scope, additional features, budget, timelines: the entire solution set is reduced significantly, allowing everyone to focus on the narrow range of solutions offered by the constraints.
For example, adding the single-word constraint of “black” eliminates most of the color spectrum, killing the meetings where palette is discussed. A cost target means you can eliminate entire categories of components. If it must be portable, there goes all the consideration of powering from AC mains. Add in “users should not have to charge or replace the battery” and now you have a wonderfully specific constraint that means 1) You need to design for low power consumption 2) Your product is disposable and 3) You don’t have to worry about battery doors or charging ports in your enclosure and can make it more protected from ingress with a simpler tool.
With a well-defined set of constraints, it may turn out that only one solution is possible that satisfies all criteria, and this is a wonderful scenario, because it means fewer decisions are required. That’s less A/B testing, faster development, faster buy-in from teams. It may also happen that no solutions are possible, and then it’s necessary to find the constraints that need to be relaxed. Of course, the earlier the constraint definition the better, and the more teams can contribute to it the more likely there will be success. For example, packaging might add the constraint that the product be no larger than a specific size so that it can fit in a standard box for cheaper shipping, and sales might add the constraint that the buttons be labeled with symbols instead of words so that they can offer it in other countries more easily. With these constraints in mind, the product development team won’t be surprised later when they have a finished product and they need to put it in a small box bound for Constantinople.
The lesson here for both teams is the same as the previous one; communication across all aspects with the ability to make decisions quickly. Whether it’s in defining the project scope or limiting it with constraints, the successful project will have all aspects considered.
Level of Investment; Money, Materials, and Effort
For every project, each team is going to have to put in some level of effort (if not they aren’t part of the project and shouldn’t be allowed to make decisions). This effort can be funding, physical resources, manpower, whatever. Reasonable estimations of the investment necessary from each team will reveal a lot about whether the project can succeed. Everyone may buy in to the idea and the features, and everyone may agree on the constraints, but unless all aspects are willing to commit to the level of investment necessary, the project will be underfunded, understaffed, or short on material. Sure, excess in one can solve another; a well-funded project could hire more staff. The point, though, is that a thorough understanding of what resources are necessary from each team, and the commitment of sufficient resources, is required.
As an optimist, I am constantly struggling with this piece. I underestimate the level of effort in finishing my projects, and I completely ignore the time and energy required to do marketing (or in my case documentation on hackaday.io), so when I’m chugging along and realize that there’s still so much to do, I’m frequently disappointed in myself. The same happens at work; we may complete the product design in record time and have working prototypes, tools designed, and complete documentation, but if packaging design is slammed, regulatory is up to their eyebrows in paperwork, and support only has the resources to handle calls for existing products, then the product won’t make it outside the lab.
Cross-Functional Collaboration Buzzword
An interesting thing can happen when everyone is properly coordinated; when everyone knows the constraints, levels of investment, and has buy-in from all the teams, then new feature requests or changes are a lot more manageable. If a product manager wants a new feature, but development says it will take a huge level of effort, customer support says it’ll be a pain to support, and sales thinks it’ll only bring on a few customers, then the feature can be reconsidered early. If the teams were stovepiped, though, the feature request might seem like a requirement, derailing the development team, and drawing focus from the other teams away from the money-making parts of the business.
I avoided using the term cross-functional collaboration until now because it sounds so buzzwordy and I’m not about the synergy lifestyle, but that corporate phrase is important and pretty accurate. In both large and small teams we need more of it. Whether it’s a solo entrepreneur who needs to consider and act on behalf of more of the aspects, or a large organization in which the teams need to communicate with each other more, in both cases, where scope is defined, constraints set, and level of investment negotiated, a project will fail unless everybody is working in sync.
How have you, in either your small one-person teams or as part of a large corporate team, dealt with this issue? Let us know in the comments below.
Hackaday Prize and Product DevelopmentIf you enjoyed this article, you should also take a look at the 2019 Hackaday Prize. This year’s global engineering challenge focuses on Product Development. It’s an excellent chance to show off many of the topics covered in this article, through our Mentor Session with product experts, and to see how other successful products come together. And of course, we’d love to see your own product as an entry.
Good testing SHOULD find these fakes, but how much can you check every component?
![Elon Musk with a very shiny new Tesla. Maurizio Pesce [CC BY 2.0]](https://hackaday.com/wp-content/uploads/2019/04/Elon_Musk_Tesla_Factory_Fremont_CA_USA_8765031426.jpg)
![A drivers-eye view of a Tesla Model X in Autopilot. Ian Maddox [CC BY-SA 4.0]](https://hackaday.com/wp-content/uploads/2019/04/1280px-Tesla_Autopilot_Engaged_in_Model_X.jpg?w=400)
A drivers-eye view of a Tesla Model X in Autopilot. Ian Maddox [![Teslas on the production line in Fremont. Maurizio Pesce [CC BY 2.0].](https://hackaday.com/wp-content/uploads/2019/04/Tesla_Factory_Fremont_CA_USA_8763129679.jpg)
_(8765031426).jpg){kind=link}
_(8763129679).jpg){kind=link}