Back
Decor-dark

Agile Product Management For Teams Big and Small

1625 words Read time 08:01

Most software development practitioners now understand what agile is. Agile compared to waterfall methodology changed competition drastically over the last 10 years. The simplest way to think of waterfall is your normal “project” based way of thinking. One thing everyone is attempting to create, and a singular outcome on that. The problem with this is that larger organizations who are servicing many consumers or customers, run into problems with this. For instance, how can they fix problems with their products quickly if they have to wait for everyone to get on the same page? It doesn’t work. Teams need the ability to rapidly iterate through problem sets large and small in order to deliver world-class value and high caliber output. Agile, is the practice of this. The ability to manage fast-paced, frequent decision making and iterations that all lead towards larger organizational desired outcomes.

Product Management is the part of addressing both a market need, a customer need, and a profit in a clearly defined path along with engineers, designers, and marketers. The combination of all parties required, working in tandem, is what I personally classify as Product.

Roman Pilcher does a great job addressing agile with this breakdown:

Agile methods embrace an age-old truth: They see change as the only constant. If flux and unpredictability are dominant forces, then our ability to accurately forecast markets and predict customer behavior is limited. Instead of employing a primarily analytical approach with big upfront market research and business analysis and detailed, frozen requirements, agile product management follows an empirical approach:

Gathering customer and user feedback on prototypes and early product increments facilitate inspecting the work results and adapting the product accordingly. The product evolves based on customer and user feedback. This not only saves time and money but it increases the likelihood of developing a great product.

Here are only a few of the high-level responsibilities a Head of Product, Chief Product Officer or other mid-level to c-level executive inside a software development organization may take on as a responsibility.

Understand customer needs and validate solutions Product Management is the internal voice of the customer for the ART and works with customers (as well as Product Owners) to constantly understand and communicate their needs and participate in the validation of the proposed solutions.

Develop and communicate the program vision and roadmap Product Management continuously develops and communicates the vision to the development teams and defines the features of the system. In collaboration with System and Solution Architect/Engineering, they also define and maintain the Nonfunctional Requirements (NFRs) to help ensure that the solution meets relevant standards and other system quality requirements. They are responsible for the roadmap, which illustrates, at a high level, how features are intended to be implemented over time.

Manage and prioritize the flow of work Product Management manages the flow of work through the program Kanban and into the program backlog. Product Management is responsible for making sure that there are enough features ready in the backlog at all times. For example, they have feature acceptance criteria that can be used to establish that it meets its Definition of Done (DoD). And since judicious selection and sequencing of features is the key economic driver for each ART, the backlog is reprioritized with WSJF before each Program Increment (PI) Planning session.

Participate in PI planning During each PI planning session, Product Management presents the vision, which highlights the proposed features of the solution, along with any relevant upcoming Milestones. They also typically participate as Business Owners for the train, with the responsibility of approving PI Objectives and establishing business value.

Define releases and program increments Owning the ‘what’ means that Product Management is largely responsible for release definition as well, including new features, architecture, and allocations for technical debt. This is accomplished through a series of Program Increments and releases, whose definition and business objectives are also determined by Product Management. Product Management works with release management, where applicable, to decide when enough value has been accrued to warrant a release to the customer.

Work with System Architect/Engineering to understand Enabler work. While Product Management is not expected to drive technological decisions, they are expected to understand the scope of the upcoming enabler work and to work with System and Solution Architect/Engineering to assist with decision-making and sequencing of the technological infrastructures that will host the new business functionality.

Build an effective Product Management/Product Owner team Though the Product Owner and Product Management roles may report to different organizations, forming an effective extended Product Management/Product Owner team is the key to efficient and effective development. Such a team also contributes materially to the job satisfaction that comes with being part of a high-performing team, one that routinely delivers on its quality and vision commitments.

Let's expand on Product Manager/Product Owners. Agile Product Management usually contains a few functional areas. One of those includes a Product Manager or Product Owner. In my personal opinion, I think it's correct when startups say Product Owners should be “Mini-CEO’s” but I also see where we fail in this categorization during the hiring process. Many Product Owners have not had true business experience. Either in or outside of an organization. For me, I feel that’s a strong foundation required, having had the entrepreneurial experience in some capacity. In fact, having failed at doing so is even more valuable than having succeeded. Because it provides that person immense insight on how to correct mistakes early and address paths that are collecting time debt.

Product Plan has a nice description of Product Owners and Product Managers

You can Google the term and find plenty of definitions, but for our purposes here we can think of a product owner as the person directly responsible for ensuring that a product gets built as closely as possible to the company’s strategic vision for it.

And the best way to ensure you are acting as a true product owner is to always think of yourself as a member of your agile development team — not a product manager outside that team. That means working closely with your developers, always confirming they clearly understand the vision and strategy before they begin building, and being available at all times to answer their questions.

Problem is many product managers, even great ones, often misunderstand or neglect this part of their role. They might perform phenomenally in carrying out their other responsibilities — communicating strategy to stakeholders, overseeing budgets and resources, synthesizing user feedback and competitive intelligence to create product roadmaps, etc.

But when it comes to the day-to-day responsibilities of real product ownership, many product managers simply fall short. It can be risky to let this role fall through the cracks in any company, but it is particularly dangerous in an agile development environment.

The often overlooked cross-functional communication task

Startups and even tech-driven businesses can have a high mortality rate. And in my personal experience, it's often when too much time and money is spent on building versus iterating with the market and receiving positive feedback from customers. This comes in the form of monetary transaction or use. The best way to avoid this is to build key relationships with other departments. You can’t simply lay out a plan to build something and expect it to be found. It simply won’t happen. You have to build strong relationships and plans with your marketing department, your sales department, your customer support department and more. Because ultimately these will be the people your KPI’s (Key Product Insights) or OKR (Objectives and Key Results) should be benchmarked on.

Product Plan has great confirmation of this

Your products will enjoy the most success when both product management and marketing (not to mention all other departments across your organization) are working toward the same goals, all operating from a cohesive strategic plan. And to accomplish this, product management and marketing need to come out of their departmental silos and begin thinking of their two departments as a larger, unified team focused on product success.

Avoid mistakes of not integrating these departments early enough. This is my favorite piece of advice from that article:

Your marketing team probably has some unique insights into what your market is interested in when it comes to your product. You and your product team are the ones who speak directly with users, but marketing oversees and likely tracks the details of their campaigns—meaning they have valuable data on which specific messages resonate with prospects enough to get those prospects to take the next step.

I hope this gives you a good first step towards thinking about agile product management, how it works, what product management is in general. There are lots to uncover as it relates to working with design and engineering. Or even when thinking about leading growth efforts through agile product ownership. But in general, this should give you an idea of the rapid-pace agile methodology mixed with the effective responsibilities required to fill the product management needs in a growing or well-established and vetted organization.

Share this article

C

Reach out