Life On Contract: Product Development Lessons Big And Small

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-In

At 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 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 Creep

We 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, 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 Development

If 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.

7 thoughts on “Life On Contract: Product Development Lessons Big And Small

  1. As for the part of “cross-functional collaboration”, just a little consideration : you need a good “scope is defined, constraints set, and level of investment negotiated ” and, along with that, good managing.

    If one of the groups considers its opinions are not heard, and always some other groups´ opinions take precedence, then they will not “buy into” your product / process, making blame for lack of success being thrown around later with accusations. Same as when one child always flee from helping wash the dishes and the others´ complains are not heard and addressed.

  2. The main lesson I learned: you are going to get much less sleep :-)

    As the owner of a very small business ( that produces embedded circuit boards for Makers/IoT, I’d love to hire a few extra people to help out with marketing, social media, fulfilment and resource tracking. This way, I could carve out more time on what I love most: product development, customer support, and spending time on the workbench.

    But to pay more salaries, you need more sales. And to get more sales, you need to do lots of marketing, social media, fulfilment, resource tracking … and yet you can’t afford to sacrifice product development, customer support, and spending time on the workbench.

    But the time you get for all this won’t go as planned:
    – You will spend way more time than you’d like with the pick and place machine (sometimes crying).
    – 1% to 5% of produced boards will need minor rework. This will take much more time than expected.
    – You will run out of a part unexpectedly because you forgot to update your “home-made” stock tracking tool.
    To add more uncertainty, you get surprisingly high sales one week and then almost nothing the next. And you are too “small” to have the tools to understand why. So you need to be even more conservative in budget planning.

    Despite all this, it’s great fun, but it’s a fight around the clock!

  3. In the real world of business, it is not the case.
    Salesmen stop visiting the customer because there is not enough money involved.
    Owners take the commissions from sales people.
    Middle mangers let other sales people work on their accounts while the middle managers don’t visit their customers.
    I’ve seen sales people bring business in and not get paid while those over them get the commissions so the salespeople who brought the business in leave.
    We hold meetings and workers submit big ideas and the company says “no” all of the time.
    Companies enter into agreements with other vendors and they aren’t allowed to sell to certain customers all of the time.
    Our company has contracts stating we are only allowed to sell certain things to their company.
    In other companies the workers have to set their goals and they don’t want to set their goals too high because they will be out of a job because their managers won’t know how to meet the goals because no one ever moves up so there is no incentive to grow.
    I’ve found business for my employers and they didn’t take it.

    My view of other companies is they are out of touch and don’t talk to the customers.
    If other companies do talk to the customers, they don’t do anything.
    Workers work in toxic work environments and there are people who get over all of the time.
    Managers don’t change the culture or care about the customer.
    Companies just want to be in the business to be in the business but they run their business into the ground.

  4. Bob,

    At our company we have standard operating procedures and they are put in place by some of our buyers to help us mitigate their risk. They are principles to mitigate risk and standard business principles.

    We have rules put in place like not to destroy any document or use white out.

    A rule to be put in place is for everyone to be human towards one another because that avoids lawsuits.

    Imagine if you were in a setting where the rules were also a problem and it took you half a day to get things done. Some people work in those environments.

    Perhaps you can develop rules to make companies develop for people instead of say “no” because owners feel that going the distance for small buyers fights against their company’s sustainability. Creative people are basically fighting laziness.

    Perhaps Hackaday should ask for submissions on company sustainability.


    1. I agree, in my past experience, it was better to be very concise about the scope of work, the schedule and a budget. The end result was that I lost a lifetime savings, the computer designer ended up unprepared for his personal computer repair shop that he had modeled with the use of all of my biz scope for computer software design. I believe that had he used his profits for his own biz development of software Engineering, he would be a very large, successful biz. Sadly, he chose to attempt repair fee tactics and noted too many online changes of browsers, preventing any type of sustainability for not only his but also my own biz. I will make another attempt, as soon as I am able to decide what platform to fit with my database and file transfer system. I do enjoy the Linux Debian Python, and hope I can select a GUI to interface with as well as a program which is not top heavy, but I am still attempting to match a more parallel software processing approach, to prevent the top heavy overbuild, over-budget and past schedule.

  5. I am in agreement with you on the need for a clear scope, schedule and budget. I also believe that prior planning is essential to assure the correct match of software with the building of and interface with existing internet protocol and the functional use of the applicable database and data entry methods. I am going to go forward with another attempt to match a data-base with Debian Python, and a GUI for the software to run along with windows. I do not know how, but I do plan on finding a way to add software features in a parallel way, so as to not have the “top-heavy” problem of over-features. I know that the clarification of the initial design may have prevented the first failure I made. I do not mind losing $250,000.00 USD, I do mind that it seemed to be for nothing. I have a copy of my software but to date, have not been able to revive it from my HDD. I am going to find out the most widely used USA database and match it with the system. If anyone has any ideas of another software program that would be able to facilitate file transfer, file organisation and a secure method for remote access from other computer workstations, please feel free to leave comments. Best regards, C

  6. As the owner of a small machine shop that specializes in prototypes, R&D, etc. I’m constantly frustrated with folks who ask me to design and build something that has never been done before without considering how much time and money will go into its creation. Recently, a young guy asked me to build a jet drive for a surfboard. He had very strict design parameters and there were no commercially available units.

    When I asked him about his budget, he replied “oh, about $500 dollars” I’m sure anyone who is reading this has had similar experiences….

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.