In our recent discussions, Sparkbox has defined a Product Champion as the singular person accountable for the success or failure of a product. Whether you’re a product manager, product owner, senior engineer, marketing director, or UX designer, I guarantee you’ll have to work with web engineers at some point. Here are a few tips about how a Product Champion can support the developers on their team.
Prioritize Clear Outcome Goals
As a developer, I do my best work when I have a clear idea of what it looks like to succeed. Product Champions are the folks who either define success or at the very least communicate what success is like to the team. Prioritizing the creation of clear outcome goals for both individual contributors and stakeholders keeps the team moving toward success.
Develop a Definition of Done
Whether you use JIRA tickets or a different way to track work, ensure that the “Definition of Done” is well defined. This is typically a sentence or two included in the work description that explains the behavior of the application after the work is complete. For example, “The buttons in the navigation match the Figma designs, are responsive, have animated hover states, and have been accessibility and browser tested to project guidelines.”
Make The Final Decision
When there are several experienced developers/engineers on a production team (not uncommon on larger teams), a difference in opinion on how to accomplish team goals will surface. It’s the Product Champion’s job to step in and choose a path forward for the team. They may defer to technical leadership where appropriate, but ultimately, a Product Champion casts the tie-breaking vote for product decisions. This allows the team to make progress and feel more comfortable as they are able to pass along some level of risk to the Product Champion.
Share Your Goals
Clear definitions of work are just one part of defining the outcome goals. A team also needs to understand what success looks like for an engagement. We had a client a few years ago that brought us a legacy codebase and wanted help improving the process to update it. We had only a few weeks to dive in, update a few pages, document our findings on the process, and make suggestions for improvements—true consulting work. Our developers left that project feeling unhappy and like they didn’t get much done since the engagement was so short, but the client and leadership thought the engagement went great. The misalignment came because we didn’t have a Product Champion, and they hadn’t shared a clear definition of success with the people doing the work. If we had someone in that role, the team would have understood that their written recommendations were just as valuable to the client stakeholders as the code they wrote. Since then, we’ve been much more intentional about sharing our goals for each engagement with our individual contributors. This is an area where a Product Champion can really shine by ensuring everyone knows what success looks like.
Be Willing to Aggressively Enforce Scope
The Product Champion is the primary line of defense when it comes to protecting a team from scope creep. Generally, the team has put together an estimated budget and timeline of a specific scope of work based on a shared understanding of the project goals, and it’s up to the Product Champion to keep that scope aligned (or gain approval to extend the budget or deadline.)
Understand Scope Creep
Scope creep is when additional features or other work that is unaccounted for in the original project plan is added to the scope. Scope creep can leak into a project several ways. Most commonly, a business stakeholder requests an additional feature be added late in the timeline, such as a flashy header or an additional webpage. Other times, the creep is from design revision, animation, or other additional specification not captured in the initial feature description. Developers aren’t innocent either. Quite a bit of increased scope can be added through dev chores like refactoring. Fighting against scope creep can seem like a full-time job, but it must be mitigated in order to protect the production team from missing deadlines.
In my early days as a developer, I learned a helpful trick for when I’ve been assigned too many tasks: ask the task assigner to help me prioritize and order the list. Though I was mostly working with project managers and tech leads at the time, this works for business stakeholders as well. When presented with a feature request for a project with a finite budget, a Product Champion could ask “What are you willing to cut in order to add this feature?” or, similarly, “We can add this feature, but if we do, we won’t be able to add that feature. Is that okay?”
Unfortunately, a lot of scope creep happens when developers start sneaking additional work into other tickets—I’m guilty of this for sure. They may feel like asking for time to implement fixes or refactors won’t be prioritized. Therefore it’s also important to make a project a safe space for voicing development’s needs and having those requests prioritized in a reasonable way.
Be Thoughtful About Team Size
Teams with large budgets but short deadlines like to “throw more people” at the problem. However, increasing team size comes with the cost of training the new team members, as well as requiring technical leadership to increase the amount of work available in a sprint (e.g. writing more tickets, reviewing more code, etc). Onboarding, pairing, synchronous meetings, vacation and sick leave, and other strains on the production team’s time adds up quickly. A Product Champion must understand these factors and work with leadership to see if adding more headcount is actually going to increase productivity.
Listen to Developer Requests
Development teams are subject matter experts in building products. A key factor for Product Champions working with developers is listening to them and trusting their expertise.
Make Time For Refactoring
The work we do is typically measured in additive code and feature releases. We work to release, ship it, and then immediately move on to the next new thing. Prioritizing work that is exciting to business often means cutting measures to refactor and improve what already exists. In a legacy codebase, developer quality of life improvements (like refactoring) keep the team motivated and increase quality for a flexible and more reliable codebase to support business needs.
Legacy codebases need regular maintenance. Several of our clients like to employ an 80/20 split of work during each sprint: 80% of the work is toward new features and 20% is allocated to whatever efforts the production team finds most important. This can be removing those todo: comments in the code itself, implementing linting or other automated testing, updating security and package versions, or speeding up the build pipeline to make shipping work faster overall.
Estimate Tasks Accurately
Speaking of sprints, many of our teams employ some version of Agile/Scrum project management. This regularly includes an estimation effort (“story pointing”) where each task is sized relative to the effort it will take to complete. Even though this can be a time-consuming practice, it is extremely important to include the entire developer team. The effort to complete a task can vary widely across a team’s skill set and years of experience. Leadership is not typically a representative sample of the full team and therefore if the only person estimating tasks is a tech lead, the estimates are likely to be inaccurate.
Consider Alternatives
It’s also important to trust the team when they size an effort. An excellent way to support developers as a Product Champion is to hear them when they suggest simpler or more accessible alternatives to complex requests, and then communicate those changes to the appropriate parties. Does your page really need that fancy carousel, or would a card grid work just as well? Do you have to have that fully custom select, or can you use the native dropdown menu? Can we use a charting library, rather than build a graph from scratch? Reducing the complexity of web elements when possible can alleviate some burden on the dev team to build fragile, complicated experiences—which translates to fewer bugs for them to fix, too.
Build QA into Processes and Budgets
Speaking of bugs, nothing quite compares to the quiet despair of starting a new sprint and seeing a large amount of red tickets: bugs. On many Agile/Scrum teams, bug fixes aren’t story pointed, as they are not new work but rather work that should have been completed before. And bugs typically pile up near the end of a project when quality assurance (QA) has finally gained access to a product before launch. Many of our clients account for a few weeks of bug fixes before a major deadline—and if you’re not, you should be—but it can still be uncomfortable for the developers to be inundated with “broken” or unusable code and interfaces. A Product Champion can be a voice for including checks at all levels of the process, reducing strain on production team members.
Build It Well
Browser testing, accessibility features, usability testing, and design polish are all common practices in building the web. Also common is our tendency to cut out these things to make room for more features. As the old adage says you only get two: build it fast, build it cheap, or build it well. Product Champions may feel more comfortable choosing “fast & cheap” because that is what stakeholders want, but it is rarely the best choice for our products.
All teams have different needs, but a good place to start is by including light manual browser testing and accessibility testing in the “Definition of Done” for every single new feature. Additionally, if possible, UI elements should go through design review before being merged into the main branch of code, as this allows immediate revisions and fixes. And, of course, every pipeline should have some level of automated testing built-in.
Save Time Later with Testing Upfront
These practices do add initial cost to an effort, but I’ve found that cost is reduced long-term in a better product with less “endgame” bugs. By advocating to include these practices in our scope, Product Champions protect their teams from last-minute scrambles to “fix” a digital product. The worst thing that can happen from testing along the way is that QA finds fewer bugs in the application or website when they go to check.
And let’s face it, no one was ever upset that a product was completed early.
Conclusion
Product Champions are advocates for a quality digital product, but they also have a responsibility to the team producing that work. By clearly communicating metrics of success, protecting scope, and listening to the subject matter experts, Product Champions can create a sustainable, healthy development environment for the engineers they work with.
Curious to hear about how our developers can support you in return? Drop us a line.
