Our Latest Content is on the FPT Blog

Feel free to browse our existing content below, however, if you're looking for the latest articles, we now post them to FPT Software's blog page

The Top 5 Pitfalls in the Product Development Life Cycle

April 16, 2020 / by Mark McLoud

What comes to mind when we say “product development?” Chances are your brain went one of two directions. Either you thought, “sweet new widgets,” or you thought, “major headaches.” If you’re in the second camp, good news! We have some thoughts on how to avoid the five major hurdles teams encounter during the various stages of new product development. But before we get into that, let’s clear up some of the basics so we’re all on the same page.

Eagle Cliff Falls, at Havana Glen Park in the Finger Lakes Region of New York State.

Just What Is The Product Development Life Cycle?

The TL;DR version is that it’s the process undertaken to bring a new product to market. Going a bit deeper, we’re talking about the software development life cycle (SDLC), which is generally agreed to have 7 primary stages: planning, requirements, design/prototyping, software development, testing, deployment, and operations/maintenance.

There are two main methodologies used in the management of SDLC projects: waterfall and agile. Waterfall is a more rigid set of steps borrowed directly from the engineering world from which software development was spawned. A generalized version of these steps looks like this: requirements > design > implementation > verification > maintenance. The use of “>” is intentional, as waterfall projects are designed to only move in one direction, down the line of stages until completion.

Agile, on the other hand, grew organically out of the dot-com startup culture of the late ’90s and is a much more flexible, “fly by the seat of your pants” (in a good way) style of project management. Agile methodology is based on a manifesto penned in 2001 by a group of software designers and programmers that consists of these four primary ideas:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

What’s important to understand for today is that both methods have their strengths and their weaknesses, yet both share many of the same stumbling blocks that can derail any software project. Oftentimes, a combination of both tactics is the best framework for the job. With this in mind, we bring you our top five pitfalls in the product development life cycle.


1) Not Doing Your Research

All of the great advice and timely warnings we can dish out won’t amount to a proverbial hill of beans if your product fails of its own accord. And the surest way to build a dud is to go in without a clear idea of the who, what, where, and why. Market research, target buyer research, and competitor research are how you answer those questions as you start off the planning phase.

Solid research skills are a must, as is cooperation between your development team, marketing team, and sales team. You need a firm grasp on who your target audience is, whether they have a need for your widget in the first place (this is especially important if your audience is internal users), and how large a segment your widget fits into. From there, you can build out not only your product itself, but the marketing and sales verbiage so the marketing and sales teams know how to talk about your product to highlight what makes it different and better than the rest of that segment.

Being well-prepared early on lays a firm foundation for your new wonder widget, possibly eliminating many of the potential pitfalls found below.

contact us

2) Falling Under The “Latest And Greatest” Spell

This one hits startups and smaller companies competing against larger organizations the hardest. It’s easy for these folks to be persuaded that the newest programming language is obviously the best choice for their project.

The problems start when you realize that your audience is most likely made up of a cross-section of the general public in terms of hardware and software being used. If you use the latest cool language that only works on the newest updated version of iOS or Android running on hardware that was just released 2 months ago, you’re telling a large segment of your potential audience that they’re just not cool enough for your product.

And when it comes to introducing a new product to market, the last thing you want to do on day one is irk the majority of your potential fan base. Using a tried and true development platform is easier on your programmers, your wallet, and your customers. 

There’s a tangential hazard to watch for here, falling for the “it’s new so it’s better” mentality. Once you’re under the sway of the latest and greatest spell, you can be blinded to the fact that for your project, it may simply not be the best way to go. Prototyping and working iteratively are the workarounds here.

A final word on this pitfall—when you use a brand new technology, you’re making yourself the guinea pig in someone else’s development cycle. And the last thing you want for your customers is to be testing your new widget without even knowing that you’re just testing the underlying tech yourself.


3) Ignoring Cognitive Biases

Humans are fallible. We fall under the sway of our own cognitive biases every day, and yes, that includes even the most hardened and experienced software developers out there. There are three that come into play in SDLC settings: confirmation bias, the sunk cost fallacy, and fundamental attribution error.

Confirmation bias

This is when we remember something historical in a way that conforms to our already held beliefs rather than being able to see it objectively. When it comes to product development the issues start when your developers don’t take into account the rest of the development work going on; instead, they only see their piece of the widget. Since they “know” the piece they’re building is perfect because they’re code-writing wizards, should a conflict arise (and they will) they will automatically see it as someone else’s problem since, again, their work is perfect.


Sunk cost fallacy

Coming to us from the world of Behavioral Economics, this one is what causes someone to overeat just because they already paid for the food. Or to stay through an entire dreadful movie to not “waste” the cost of the tickets. Just because you’ve spent some of your budget going down a certain path doesn’t mean it’s automatically the right path. Sometimes it’s best to pivot and move on to a new trail rather than continuing to throw new money at the old that’s already gone.


Fundamental attribution error

Also known as correspondence bias, this is when we under-attribute situational explanations for someone else’s behavior while over-attributing dispositional ones for our own. For example, when someone cuts you off in traffic and speeds off, they’re a jerk. But when you did that yesterday, it was because you were late for an important meeting. When teams butt heads over the direction of a project or the role each team is playing, this will rear up and make itself known. Obviously the other team is just being obstructionist so they get more credit, right?

The solution for all of these biases is to incorporate feedback loops that include outsiders for truly unbiased input. That way, your teams get input from someone other than who they’re working directly with and you as management get impartial input on how the project is progressing and how the finished product looks to these outsiders.


4) Not Having the Right Human Resources

When small to midsize companies try to be everything to everyone, failure is inevitable. And the most common reason for this is overconfidence that your people are like swiss army knives that can do everything. They aren’t. You wouldn’t ask your finance department to work on designing the new UI, would you? So why assume your full-stack developers are also designers?

Having the right team in place from the beginning of a project is crucial for staying in budget and on time. A recent development in this area is nearshoring. This is where you hire a full development team located in another country, yet still in a nearby time zone, or even your own. Now you only need to have the project manager on staff, and they can work directly with this pre-existing team on a mutually agreeable schedule. No more emergency calls at 2:00 in the morning.

This solution is also ideal for one-off projects. Say you’re mainly a web development organization, with plenty of full-stack programmers and front-end designers. What you don’t have are any app developers or mobile experts. When the time comes to make a mobile version of your latest widget, what do you do? You nearshore and get a full team of mobile specialists at your disposal, ready to build that app on time and on budget. And after the project is complete and on the market, you don’t have to worry about how to reassign those app devs.


5) Not Having the Right Technological Resources

Once you have the people-power sorted, it’s time to look at your computing power. Is your in-house stack outdated or otherwise not appropriate for this product cycle? Are you still using a 3-versions-back stack on on-site servers in the closet? Trying to build a cutting-edge widget with that infrastructure may prove frustrating, or worse.

There are options here, primarily going with the cloud or once again looking to a nearshore operation. Cloud computing has several distinct advantages over upgrading your in-house setup. First, you’re not paying for all those upgrades or the new hardware needed to run it. Instead, you’re paying for a subscription to access someone else’s infrastructure running the latest environments. When the build is done, you can stop your subscription to cut costs.

With nearshoring, you get the advantages of cloud plus the human power of the team discussed above. You see, these teams come with their own infrastructure, on-site at their location. You’re paying for the project as a whole, they’re covering the costs of having the hardware and software they need in order to complete the job you hire them for.

Any and every product development project in the history of product development has had hurdles. When you’re aware of what to look out for, it’s that much easier to avoid them, keeping your SDLC running smoothly and keeping your projects on time and on budget. We hope this look at our top five pitfalls in the product development life cycle will help you do just that when it’s time for your next product to go into development.


Learn More About About Intertec's Custom Software Development:

Intertec offers a wide spectrum of options in custom software development. We provide personalized technical services throughout the software lifecycle,  customizable at all levels of integration with a client’s existing team. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here

Tags: Project Management

Mark McLoud

Written by Mark McLoud

I was raised in a rural town in the state of Iowa where I learned the value of hard work. My passion is working hard for my clients and colleagues with enthusiasm, responsiveness, and creativity. As the late, great Vince Lombardi once said, "The harder you work, the harder it is to surrender."

Contact Us