Products Are Hard

You are here: Home / Archives for Team Dynamics

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:

Text trumps video for remote teams

By

Over the last few years we’ve done a fair amount of work with remote development teams. One of our current clients is going through a company-wide transition from waterfall to agile, and they use remote contractors extensively. A primary goal of the transition is to make better use of the full talents of their engineering team, so good communication is essential.

When working with remote teams, it’s tempting to try to replicate the experience of an in-person meeting. Google Hangouts make the features of much more expensive teleconferencing products available to a wider audience, and increasingly we see companies set up their conference rooms with large monitors hooked up to a simple webcam to use Hangouts or Skype.

The aforementioned client uses Google Hangouts as a matter of course for all interaction with engineers, putting heavy emphasis on video conferencing in an attempt to make the remote developers feel more a part of what’s going on. In sharp contrast, a different client holds their morning stand-up meetings exclusively on IRC (even when they’re all in the same building) – old-school, text-only group chat.

Text works better in most cases.

The simple truth is this: giving a meeting your full attention is hard enough, but giving a meeting your full attention when you’re attending remotely is impossible. This is particularly true when you’re a remote software engineer and the topic is something other than the particular bit of code you’re working on. Remote developers are not going to give their full attention for the entire duration of a meeting. It’s not the way our brains work.

Three more concrete reasons we prefer text-based remote discussions:

  1. A text-based conversation is much more forgiving of momentary distractions. If I zone out of the discussion for a minute while I answer an email I can quickly catch back up by reading the transcript.
  2. A text-based conversation ensures everyone gets their ideas in. In a voice/video conference it can be difficult to know when there’s an appropriate pause in the conversation to interject. When an engineer in Bulgaria is trying to provide input to a conversation happening in a room in Mountain View, they need a way to interject without having to force their way in.
  3. A text-based conversation can be reviewed later. If someone misses a meeting or arrives late, or if you need to refer back to the discussion after the fact, a text-based conversation is there waiting for you. This also frees everyone from needing to scribble notes furiously while the meeting is in progress

Video and voice have their place. One-on-one or small group chats can benefit from the immediacy of video. If the remote party is leading the conversation or presenting it can also be beneficial for everyone to see that person. If people are not expected to participate and just listen it can be nice to be able to hear and/or see the person presenting rather than needing to read. Text works well when a group of people all need to participate.

Google Hangouts can serve both purposes as it has text-based chat is built right in. IRC is the classic text-based chat, though modern products like Campfire, HipChat, and other online collaboration tools are more manageable if you don’t already have IRC set up (built in logging, image rendering, file uploads, etc. are some obvious features IRC doesn’t offer easily).

Chairs with wheels

By

A former colleague once told me a story that delightfully illustrates the nature of business decisions relative to technology:

Years ago he was pitching a big consulting project to a major telco. The telco had put out an RFP to various development shops asking for help solving a classic problem — they had a number of different systems for billing, provisioning, customer service, etc. Their customer reps would have to physically go to different terminals to deal with different aspects of the support process, causing a lot of inconvenience and wasted time.

Of course, all of the proposals that came back talked about various ways to integrate the systems using then state-of-the-art enterprise software techniques, and, of course, all of those proposals were quite hefty in terms of time and cost. My friend submitted his proposal and waited to hear back.

After a couple of weeks the telco got back to him – he did not land the project, but not because some other shop had beat him out. No, you see the telco told him that they had bought all of the customer reps chairs with wheels on them, making it much easier for them to move among the various terminals, so they no longer considered it a burning problem.

True or not (the guy who told me this story swears it’s true) this parable puts all technology decisions into perspective. Wheels on the chairs! Minimum Viable Product, indeed. When tackling hard problems, always look to see if you can find a “Chairs With Wheels” solution before (or, in many cases, while) investing in technology solutions.

Get in touch

415.683.6936
@productsarehard