Product discovery

Music, Product discovery

On iZotope’s Product Development

No Comments

I’m a music buff. In fact, I’m a bit of an amateur producer, creating music “in the box” whenever I can.

In the box means I pretty much exclusively use my laptop or iMac as a recording studio. The audio production tools available to producers and musicians are stunning, and used by every top studio on the planet, pretty much. Exponential growth in computing power has allowed this.


But with all this power comes great responsibility. The users of such software care deeply about their music, and that’s what they want to focus on. But the world of audio engineering is highly technical and can take years to master. So how do software companies that create digital audio workstation (DAW) applications, and their associated plugins, marry this need to be creative with the deeply technical nature of production?

One such company is iZotope, based out of Cambridge, Massachusetts. They’ve been developing DAW plugins (all DAWs have an architecture that allow them to be extended using plugins developed by 3rd party companies, like iZotope) for years. They’ve made headlines recently with the release of iZotope Neutron.

Take a look at this short video describing how they tackled writing such a complex piece of software. You don’t really need to understand what it does; instead notice how they talk about pair programming, TDD, and code reviews. You’ll probably spot developers demonstrating software to their peers, and I think you’ll catch glimpse of what looks like a User Story Map.


Product discovery, Scrum

On Discovery Of Product Discovery


What A Difference A Year Can Make!

About this time each year, I don my scrum master cap and visit the University of Sussex to deliver a lecture to under graduates and MSc students on Scrum. And each year I find myself having to modify my lecture to take into account the ever-changing state of the framework and the experiences I’ve picked up during my agile travels.

Some lecturers might find this constant evolution a pain in the ass (after all, rewriting a lecture isn’t exactly fun), but I think it’s testament to how awesome practices like Scrum are.

What A Difference Three Months Can Make!

Earlier this year I quit my relatively secure scrum master job in Brighton to go freelance. It was a daunting move with, typical of so many big decisions, the procrastination being more painful than the execution. I walked into a scrum coaching role expecting to use my well-practiced skills on a new scrum team. You know the stuff: mess with the rituals, add some vigour where it’s needed, help the team find their happy place. All great stuff and indeed the bread and butter of scrum mastery (yes, I know there’s way more to it than that, but I need to keep this post relatively short and most of you know this stuff already, right?).

If you spend too much time thinking about a thing, you’ll never get it done. – Bruce Lee

The team’s product owner is a really bright star, eager to take the product to another dimension. I recall having a chat with him over coffee about roadmaps. We were talking about Roman Pichler, goals, MVPs and all that well-documented awesomeness and I dropped into the conversation that I particularly loved Jeff Patton’s work on User Story Mapping and Gojko Adzic’s Impact Mapping techniques. I’d been aching to use these techniques more and now I had an opportunity to introduce them to a team that hadn’t dipped their collective toe into such waters. I eventually ran a User Story Mapping workshop with the product team. I ran five Impact Mapping sessions with “the business”. Both techniques were received positively.
But I found myself questioning the validity of it being me doing this work. “Is this a normal scrum master duty?” I asked myself. “Am I abandoning my teachings?” I postulated as I rubbed my stubbly chin.

Intellectual growth should commence at birth and cease only at death. – Albert Einstein



Fast forward to today. I’m now no longer my client’s scrum master. Instead, I’m their newly appointed product coach, helping the product management team adopt discovery and delivery techniques, otherwise known as dual-tracking. The work I’m doing now is upstream of the typical Scrum team. We’re focussed on creating experiments, challenging assumptions, hypothesis testing, rapid learning, and user development. Of course, all of these artifacts and rituals can be considered to be under the general agile and Lean umbrella, therefore my experience as a scrum master is still relevant and applicable. But am I a traditional scrum master? I don’t think I am any more. My eyes have been opened to the value of product discovery, and I’m hooked.
I wonder how many of you reading this have found yourselves on a similar path. Please share your experiences in your comments.