Over my years in this industry, I’ve guided a wide variety of teams to software success. And along that journey, I have found that many product teams struggle with the same issues.
How do you know if your team is suffering from a particular product development problem? Most likely, you’ll notice some signs. Below, I’ll describe three key problems most product teams face and the symptoms of each. In addition, I’ll discuss some of the immediate benefits of overcoming these challenges.
Root Problem No. 1: Your Team Operates With a Project Mindset Rather Than a Product Mindset
If your team is more project-minded than product-minded, you might notice the following symptoms:
- Your people think of scope, budget, and timing as fixed.
- The dev team wants everything to be absolutely perfect before launch.
- User interviews have fallen by the wayside.
- Your team focuses on the execution of written requirements at the expense of everything else.
Teams who are stuck in a project mindset rut are often too afraid of failure. They’ve likely experienced the negative results of software projects done poorly, such as never-ending timelines and wasted money.
As a result, they now spend months mapping plans and writing requirement documents as they work toward a singular goal. We get it. Before our team realized the benefits of a product mindset, we too would try to predict every detail upfront and wouldn’t release a product until everything was completed.
However, when companies and teams adopt a product mindset, they quickly gain the ability to properly manage their scope and reduce their fear of risk and failure. A product mindset reduces the risk of wasted time and money by ensuring a functional MVP that can grow and evolve over time.
My company, Augusto, works with product teams to help them streamline their development process. When companies eliminate this “project over product” mindset, our team of developers at Augusto is able to accelerate the way they do business by quickly creating a tangible product that drives value.
Root Problem No. 2: Your Team Focuses More Heavily on Scope than Value
Below are some common signs that your team is overly focused on scope at the expense of value:
- Your leadership team has more ideas for features than your team can actually implement.
- Your development team is constantly fighting scope creep.
- The lead developer seems to be in charge of the product.
- No one is discussing the desired outcome of the project anymore.
Teams who focus too heavily on scope aim to identify every detail upfront, often because they start with too big of a vision. More often than not, they then experience disappointment and frustration when the scope of their project inevitably changes.
Originally, project management focused on the construction of physical spaces: bridges, buildings, anything concrete. Teams absolutely had to identify every single detail of their scope up front, because one mistake could bring the whole project tumbling down. Also, any changes down the line would incur huge expenses.
However, the nature of software projects requires (and allows for) more flexibility. When teams focus instead on value over scope, our developer team at Augusto is able to produce an MVP, then test it with customers and other stakeholders. This research almost always uncovers ideas that allow us to adjust our path accordingly and position the company for ongoing growth.
Since almost every project undergoes changes in scope, we abide by the pattern of sprints and cycles to allow for flexibility, growth, and realistic expectations.
Root Problem No. 3: Your Team Doesn’t Understand How to Organize Digital Product Development Work
Here are some of the symptoms of insufficient understanding of how to organize a digital product development team:
- Your teams haven’t studied product development, but rather come from disciplines like development, marketing, or business.
- Team members aren’t thinking iteratively and instead prefer big-bang releases.
- Teams are inward-focused and think they know more than anyone else. There seems to be a divide between the development team and the business team.
- The product owner isn’t clearly defined; product launches are managed by the development team.
Teams who are unfamiliar with agile development typically experience both rigidity in their processes and a tendency to accidentally overspend. In my experience, many of my company’s new clients have been burned in the past when presenting a budget to a vendor, so they’re often hesitant to adopt this way of working.
However, our approach is to take any size budget and deliver the most value possible for that amount. The value proven from that first cycle will earn more budget, if necessary, to meet the goals of the software or the overarching business goals.
The successful strategy we use to do this is organizing our timeline and priorities by six-week cycles. This concept works brilliantly in software systems because these products don’t fit neatly into compartments; rather, they evolve over time. The biggest benefit to working in six-week cycles is that we build the right system for our clients, even if it’s not exactly what they predicted at the beginning.
Continue the Diagnosis
Of course, your team may be dealing with more than one of these problems at once, and the symptoms might be quite subtle. Continue to monitor team performance and track progress against your product roadmap at regular intervals. And don’t expect the development process to be perfect — instead, focus on iterative improvements and asking the right questions.
