Why You’re Not Getting What You Expect From Your Product Development Model.

As modern technology has progressed, organizations have established internal teams to build various solutions within their walls. Whether these solutions are websites, proprietary systems, tools to manage their work, or something else entirely — when standing up a practice of developers and their counterparts (project managers, designers, testers, etc.), the organization typically jumps immediately to ‘let’s work Agile.’

Alternatively, some organizations have housed and managed solutions for decades. Those solutions are supported by teams who have worked via older processes (aka Waterfall or no process at all) for the duration of their time together. These organizations tend to seek ways to work more effectively, efficiently, and with a more modern touch, and therefore ‘Agile’ seems to be the solution.

Either way, while an organization may have the best intentions by spinning up ‘Agile’ processes or establishing a product development model to support their work via ‘Agile’ processes — more often than not, the work will undoubtedly encounter speed bumps.

Some points of view are important to baseline (how certain words are used within this post) before jumping into this topic.

• Agile — a way of working that supports the completion of tasks iteratively. While different people define this in different ways, I think of it as enabling a process type that promotes incremental work vs. holding everything hostage until the end.
• Product Development Organizations (PDOs) — Organizing principles, ceremonies, and processes activated to bring an everlasting thing (product) to life, leveraging autonomous units to build the whole.

In general, while Agile and PDO are not synonymous with one another, they tend to go hand in hand. Product Development Organizations typically desire continuous improvement, incremental releases, and a customer-forward view; therefore, leveraging various Agile processes inherently supports these efforts. Unfortunately, Agile and PDO are not something that an organization should step into lightly, yet often they do. As time passes, the model and processes established in this effort break down. These breakdowns can drastically reduce velocity, result in products dying and teams falling apart.

We often don’t identify why these things happen until we evaluate the holistic situation in retrospect, but, here we’ll outline a few common problems that may be the culprits.

Understanding why the below are fundamental issues comes from aligning on what Product Development requires (at a minimum):

• All stakeholders/business owners are aligned with how a team will work, how a team will output, and what they require as input. If the organization isn’t aligned to this, then dependencies are created right out of the gate that aren’t connected.
• Dedicated resources. Roles such as Product Owners and Product Managers must have the ability to focus (and own/be held accountable) their remits. Shared resources or not appropriately engaged (absent) team members can create blockers to getting work done.
• Contain the flow of work. One of the core goals of working in this fashion is autonomy; enabling people with a common goal to operate entirely autonomously toward a holistic product. When dependencies exist, the proper state of independence can be challenging to achieve. For example, if all of your designs and requirements come from an entirely different business unit that does not work in the same fashion.

When any of the above aren’t met, your organization may not get out of Product Development what they’re expecting.

The organization, fundamentally, isn’t aligned.

Suppose the entire company isn’t willing to support working through Agile processes, and you’re dependent on units within the business outside of your own. In that case, you’re immediately creating a barrier to success.

An example of the challenge: your IT team has to work with other parts of the organization to get work done. In some cases, there may be a person within Finance that, is for all intent and purposes, your product owner of a specific feature set. They also must provide all compliance requirements for a workflow that distributes content outside the firewall. This individual can only provide prioritization time monthly and hasn’t funded anyone on their team to support the product itself.

How to pivot & work toward correction:

Unfortunately, as with many things in life, there are no ‘one solution fixes all’ because every organization is different. In this scenario, there are some things you can do to start a path toward correction:

• Get to the top. Work with executive leadership to sell in the model and way of working and include expected ROI on working the way you’re proposing. Ensure their alignment is made clear to the rest of the organization through communication and budgeting.
• Research, identify and propose resources that can migrate from outside in. Your organization may be able to support a cross-functional Product Development Organization that self contains all of the functions it needs.
• Start small, grow big. Often there is a threshold to how much you can start with. Find a little thing that can operate as an autonomous unit and test the model and processes. Once established, add another, then another. Evolve the model instead of just ‘launching’ the model. This may sound counterintuitive to the whole organization being aligned but focus on autonomy within this solution.

Right people, right roles.

Just as a properly trained racecar driver should only drive a racecar, PDOs can only effectively be led by those who are trained in the practice. Each role within a product team provides a unique remit to the team. Without understanding their part, the model tends to break fairly quickly as the team doesn’t get the direction and input they need to operate.

An example of the challenge: your team’s product manager comes from the Legal team. The individual in question sought a new opportunity, and the PM position for your PDO was open. This individual managed tasks and output in their former position but wasn’t provided any training for the new job or understanding their responsibility areas. The team is lacking any ceremonies by which to produce their work.

How to pivot & work toward correction:

There are a few tactics that can be activated reasonably quickly to begin correcting this issue:

• Find training. There are tons of outlets where individuals can find various types of training. Start internally. Within your operating model, there may be strong individuals performing a role who can mentor others who need help. For example, if you have a strong Product Owner, pair them with the Product Owner who is new to the position for the 101 fundamentals. Outside of that, plan on (and activate) budget to send individuals through 3rd party training, even if online, to learn some of their job's core functions.
• RACI. When team members don’t know where to be or what to do, they tend to try to be everywhere and do everything. This both creates conflict and duplicativeness. A simple RACI (a matrix showing who is responsible, accountable, a contributor vs. someone just informed) can help the team know where to be and who should be doing what.
• Start somewhere. Just because one person doesn’t know something doesn’t mean everyone doesn’t know anything. Simultaneously, as certain individuals are learning, find someone with experience to set up some conversations/forums to start working better. These ‘ceremonies’ can be changed over time, but without any formalization of the process, the team will continue to be directionless, and output will be minimal.

Deadlines or a ‘Big Bang’ approach.

Understanding deadlines and milestones with a PDO requires a belief in balance. If you have nothing you’re driving toward (e.g., an MVP — minimally viable product), you’ll end up in an indefinite development cycle. Working against a deadline the product team itself doesn’t control (e.g., a fully paid media campaign for its release) is of equal detriment because the idea of iterative releases breaks as you’re working toward one big release.

An example of the challenge: your company wants to start a brand new product line but isn’t willing to fund it on investment; therefore, a client is sought out to fund the initiative. The client is willing to invest, but only if they can launch by June 1. The date isn’t negotiable, nor is the feature set required to pay for this venture. The result of the client pressures is that the product team’s need to ideate, test, release, test, etc., is diminished if not entirely removed because their time is restricted.

How to pivot & work toward correction:

In this scenario, the team may need to shift direction so that the working methods that come out of the first release are not ways of working that should be used as baselines for future development. Acceptance of this can lead to:

• Relief. Once the team understands they’re not working in an ideal state, expectations can be set differently. The team can work against the release rather than rage against the process.
• Aligned goal. It is OK to get a ‘thing’ released and then reframe; in fact, doing so can help the team use their learnings to improve.
• Set expectations. As much as the team needs to understand the goal and expectations, so do clients and stakeholders. Instead of promising something released iteratively, creating pressures on the team, streamline expectations to reduce churn and frustration.

You’re not feeding the machine.

A product is a living, breathing thing. Once the first round of development is complete, product teams focus on the growth and optimization of their product. At a minimum, the product can progress through user-testing, a backlog of features that fell out of MVP, ideas to be explored, and technical debt remediation.

An example of the challenge: Now that you’ve gotten the product off the ground, things have stalled. The team doesn’t have a backlog to work from or even a list of things that need to be done. Furthermore, once the product's initial design work was complete, the designers were taken off.

How to pivot & work toward correction:

Most immediately, get the ideas flowing. Pull everyone into a room — business owners, product owners, designers, developers — and start ideating. Talk about the work to be done, where the product should progress to and lean on the Product Owner to prioritize focus. Build the backlog, then focus on the distribution of time.

• Backlog building. Start simply by creating a list of things, then shape the ideas into properly sized efforts; epics for big things that may take multiple months, stories and tasks for small tweaks to something already out there. Spread these out by priority (where the focus should go first) and build a few sprints.
• Technical debt. There is always some degree of technical debt in a product. This debt can be remediated by creating tasks within the backlog to correct it. Some debt remediation may require small code changes to clean things up versus full refactoring, but in any case, it should be accounted for to optimize the product itself.
• Capacity plan. Once you have your backlog built, even if just for a sprint or two ahead, work on how much time will be spent by the team where. Meaning — identify if the team will spend 60% of their time on net new feature work and 40% on debt remediation or some other allocation. This will help set the business's expectations on what output will look like.

Regardless of the challenge you might be having, the strongest recommendation I can give you is don’t throw the baby out with the bathwater (as horrible as that idiom is!) Instead, use the process. Hold your retrospectives, look at your data, explore perspectives, and find places to optimize. Bring in a consultant to help if you need to. There might be many issues, but you can fix them over time and grow into a genuinely productive organization.

I’ve spent my twenty-year career helping organizations build processes and operating models to execute work efficiently and grow strong, healthy teams through modern best practices and common sense. All of the above is opinion only, based on experience. Learn more about me: https://www.linkedin.com/in/melissagreen/.

Photo by Startup Stock Photos from Pexels