Products Are Hard

You are here: Home / Archives for Product Management

The age of holistic product development

By

Over the last decade a few major themes have dominated the evolution of product development, particularly software development: a shift towards agile practices, customer-centric decision-making, and better integration and collaboration across disciplines. The last of those – the increasing porousness between the “Big Three” disciplines of product management, design, and engineering – is evolving the most rapidly. The tenets of Agile development are fairly mature at this point. Customer development and Lean practices are now considered conventional wisdom. But the ways in which designers, product managers, and engineers work together are in flux. The boundaries between the Big Three pillars of product development are just beginning to blur.

Design has changed the most dramatically and had the most significant impact on engineering and product management. A decade ago design was little more than static mockups or graphic treatments of engineering output. Today, not only is design key to creating successful products at all stages of the lifecycle, it has also become a viable strategic differentiator for the companies that do it best. Design as a discipline has always encompassed more than just the façade (the “chrome” as we called it before Google appropriated the word). In software, however, only recently has design been acknowledged as a major strategic input. Product managers are the voice of the customers, but designers are the voice of the humans.

Designers in software have also become more rigorous and technically proficient. A shiny mockup that gives a good first impression was all a good designer used to have to make. Today we expect the design process to start from a clear set of first principles derived from a deep understanding of the people using the product. We expect designers to understand information architecture and to create a consistent, reasoned visual vocabulary and a sensible flow. We expect designers to intimately understand the capabilities of the technologies used to implement their ideas, and increasingly we see designers with substantial software development experience working with the same tools as engineers.

The evolution of design has impacted product managers and engineers as well. Product managers are now expected to understand and utilize design thinking. Engineers need to be conversant in the design vernacular and are becoming increasingly skilled in basic design principles. These cross-pollinations are a healthy development, and as the last vestiges of linear, waterfall-style processes fall away, teams are looking for ways to integrate their efforts and break free of assembly-line metaphors (GANTT charts are not exactly in fashion in software development). Classic Scrum orthodoxy has also left teams looking to loosen the bottleneck created by a single Product Owner who must be the conduit between the entire business and the Team. At the previous two Products Are Hard conferences, for example, we saw a great deal of interest in talks about ways to better integrate designers into the development process.

We use the world “holistic” to describe this evolving approach because of the convergence of disciplines, processes, and strategies that are all based on integrating across disciplinary boundaries. Designers, product managers, and engineers are influencing each other and are working more closely than ever before. We have built new processes to favor responsiveness and experimentation over predictability and certainty. We have pushed our business strategy to be more informed and harmonized with the human needs and desires of those we build for.

We’re curious about your experiences. Are you seeing a similar trend? Different trends? Let us know: @productsarehard

Sprint is a four-letter word

By

I’ve always been uncomfortable with the term sprint. It’s a short word, easy to say and quick to type, but the connotations can be misleading, especially for people new to Scrum. I used to run track in high school, and I have a pretty vivid body memory of what it felt like to sprint – an all-out blast of energy expenditure that left me panting, heaving, and, sometimes, if I’d pushed hard enough, even nauseated. I was no Usain Bolt, but I wasn’t a slug either. I was a regular person, reasonably able to run pretty well. It left me in no condition to do anything but sit there recuperating until my muscles and lungs stopped screaming and returned to functioning normally.

You can’t sprint your ass off, pause for a minute, and then do it all over again. It’s not sustainable. And yet one of the most important benefits of the Scrum framework is that it provides a sustainable rhythm for work. It’s meant to be the opposite of a death march or a self-destructive series of Jolt-fueled all-nighters followed by days of hibernation and recovery.

There’s always the argument that after enough use, the word itself becomes a signifier for the concept and its connotations become less relevant. Who, after all, thinks about chitinous little bugs when talking about John, Paul, George, and Ringo? But words do matter, otherwise we’d refer to everything with algebraic letters, symbols, or glyphs. So, no, I’m not proposing that we start referring to sprints with Σ (even though that would be awfully cool), but language being what it is, the other commonly used terms are each fraught in their own ways. I tried using iteration for a while, but Nathan found that made people think about dozens of tiny, obsessive refinements towards a specific ideal. Sprints are about getting shit done and perfect being the enemy of good, most definitely not about obsessiveness or idealism. Timebox, another common-ish term, feels cold, bureaucratic, and constricting. So, in the spirit of Scrum, we continue to try out different words, getting a sense of how well they do or don’t work, and we iterate our way forward. We may never have the definitive word, there certainly isn’t a perfect one, but in the meantime we’ll keep talking, training, coaching, and working.

UPDATE: Sasha Magee offered some interesting proposals from the sport of cycling:

The five pillars of product management

By

A few years ago, as I prepared to leave a product manager position, I trained a junior member of the team, someone new to the role of product management, as my replacement. I told him the role comes down to the following five elements.

Gather

A huge part of product management is simply knowing what’s going on — what people do all day as it relates to the product, what kinds of things they wish they could change, and how the various constituencies interact. While most product managers have plenty of good ideas on how to improve the product, gathering ideas from and identifying problems in the rest of the organization are just as important.

Synthesize

As ideas and issues emerge, a product manager must create connections where others do not see them. Two groups in an organization may have two very different problems. A product manager should be able to find a way to make a single, better-abstracted view of the underlying concern. Synthesizing also involves creating named themes, initiatives, and goals for a product. Never underestimate the power of synthesis to create common understanding and bring sanity to the chaos of “line item” requests. Synthesis is also instrumental in winning the hearts of product team members.

Prioritize

Choosing what is most important is an art. Deep understanding of business strategy, market realities, and resource capabilities is key. Knowing what’s hard vs. what’s easy and what’s of broad vs. narrow value helps to create a prioritized list of the various tasks to be completed. Given infinite time and infinite resources everything would be possible, but in the real world, making the hard choices (or, more importantly, helping the rest of the organization make the hard choices) becomes one of the central functions of a good product manager.

Define

A product manager must own the detailed definition of what the product should do so that engineering knows what they will build. This involves plenty of documentation, though much less than you probably think. Document only as much as you have to. Don’t create detail for detail’s sake. With web-based software the need to be quick and iterate frequently makes it essential to move forward with imperfect information and adjust as you go. If you’ve been an engineer or worked closely with engineers, you know the unique horrors of changing the spec and the dread of feature-creep. Part of the reason for the rise of agile methods is that rather than constantly reacting to attempts to get to a “finished” spec of a project (only to see that spec change in the middle of the cycle) engineers started to simply build the dynamic nature of requirements into the system. “Define” does not always mean writing down as much as being the Source of Truth.

Shepherd

A big part of my day as a product manager involves, quite literally, walking around the building. Keeping all of the balls in the air is a critical part of product management. In most organizations there is nobody else who sees all the various pieces and how they must fit together. Many product efforts require coordinating distributed efforts towards a single destination (and doing that over and over again). In my world, having the engineering “done” is only about 2/3 of the process. Once the actual “product” is at a finished state, packaging, documenting, training, and distributing all remain.

When I first put these 5 elements on a white board I wrote the word “CONTEXT” next to them. Ultimately, you must undertake all of these activities with a full appreciation for the business as a whole — the goals, strategies, capabilities, culture, and, most importantly, the people.

Product is a curious function. It is often under-appreciated, yet it is also the domain of some of the most powerful people in Silicon Valley. Product people must be generalists while also obsessing about small details. They must cross cultures within their organizations. They must be able to step outside the organization and sit on the same side of the table as the people for whom the product is made. It’s a hard, rewarding job and it’s the glue that holds many great organizations together.

 

Get in touch

415.683.6936
@productsarehard