Your ideas could be messing up your product roadmap. Yes, you read that right. Wait, aren’t great ideas the fuel of a good product roadmap? Sure, to some extent. But are you suffering from challenges like having a hard time sticking to your roadmap and delivering against it? Half-done or low-quality features? Constantly switching priorities, or too much WIP? Well, it may just be because of your ideas.
Words matter. Language matters. Single words can evoke a whole set of connotations and feelings. In the Agile space, the word “waterfall” certainly does that. Every language domain, such as an organization or field of practice, has these words or phrases that have a very specific meaning understood by everyone who’s part of that group. Sometimes they’re neutral, sometimes positive and sometimes they’re just taboo — words you better avoid due to the bad aftertaste or overwhelmingly negative connotations. In a different context or domain, the same word may be completely innocent and neutral — just ask hikers about waterfalls. (In one organization I worked for, you should never mention “productivity”; otherwise, you’d immediately be confronted with visceral reactions and backlash!)
There are an increasing number of books out there about various aspects of product management. Here are some of my favorites which will hopefully be useful for both aspiring as well as experienced Product Managers and entrepreneurs:
Marty Cagan’s INSPIRED: How to Create Tech Products Customers Love is a must-read. He covers everything from the structure of the organization, ideation and discovery to scaling the business. In this 2nd edition, he focuses not only on start-ups, but also on growth-stage and large companies.
The Lean Startup is a classic. Eric Ries, in this milestone book, makes the case for the discipline of entrepreneurial management (Vision), dives into the details of the build/measure/learn loop (Steer) and shows how to accelerate learning and scale the business (Accelerate). (Also, check out Eric’s 2nd book “The Startup Way”.)
Hooked: Nir Eyal takes his readers on a fascinating journey into the Hooked model and explains what it takes to use habits to create “sticky” and engaging applications that users come back to again and again. This book will be particularly intriguing to those of us interested in human behavior, psychology, and brain science.
The Lean Product Playbook was one of the first books I read when getting into Product Management. Dan Olsen does a great job of walking his readers step-by-step through the process of determining target customers, identifying underserved needs, defining the value prop, and, building and refining the MVP. Furthermore, he also gets into how to use metrics and analytics to optimize the product.
Running Lean: As the master and creator of the Lean Canvas, Ash Maurya shows how to not just create a product, but a viable and scalable business by documenting a plan, validating the riskiest parts, and testing the plan qualitatively and quantitatively. (Another great read of his is the follow-up book “Scaling Lean”.)
As it turns out, many very successful entrepreneurs such as Elon Musk and Mark Zuckerberg have one habit in common: they read a lot! I hope this list is inspiring you to keep reading and learning about the expanding field of Product Management.
What are some of your favorite product-related books?
Distributed Agile teams are here to stay – like it or not. According to CollabNet/VersionOne’s 12th State of Agile survey, 79% of respondents had at least some distributed teams practicing Agile. I myself was taught early on that Agile teams had to be co-located and should sit in the same area in order to facilitate high-bandwidth osmotic communication. And while that is still a very effective way of working, in today’s workplace we see more and more distributed Agile teams.
For the sake of this post, I will focus on team members distributed geographically across the country or globe, less on people in adjacent buildings or on different floors. I will cover:
Why distributed teams are becoming more and more popular
The truth is that measuring things in software development is hard. As Edwards Deming clearly stated “The most important things cannot be measured.” We’ve all seen how metrics can be gamed and abused (velocity, anyone?) and many have heard of the “Law of Unintended Consequences” and experienced in practice how measurement led to unintended and counterproductive behaviors. So a lot of folks have jumped on the #NoEstimates bandwagon and we’re all better off not measuring anything at all, right?
I’m not sure it’s that easy. The reality is that we’re all living in the business world and we’re being asked to help answer certain, very valid questions, such as:
What’s our customer satisfaction? How is it trending?
How are our Agile teams doing? Are we getting better?
How is our Agile / digital transformation progressing?
Are we getting the value we were hoping for out of our transformation efforts, coaching, etc.?
What ROI are we getting from the money we invest in our transformation?
For consultants and coaches: Am I moving the needle and making an impact?
Are we helping the organization deliver value faster?
Where do we need to deploy our limited coaching resources?
What bottlenecks in our value streams do we need to address?
While measurements are hard and there are certainly landmines to avoid, … Continue reading my full post here.
Everyone loves a “can do” attitude. “Yes, we can!” has become – even when stripped of any political connotations – the rallying call of an entire generation, empowered, driven, and enthusiastic. For a young startup, this type of optimism is a prerequisite. Pessimists would probably never embark on a dangerous journey into uncharted waters, let alone survive the trials and tribulations that are an integral part of bringing a new product to market. But as startups grow, …
Continue reading on ProductCraft (where this full post has been published)
Product Management is a newer “function” and many companies don’t employ it from the beginning. Instead, it tends to emerge over time as companies start focusing on making their software products better. I’d like to describe a common pattern I’ve seen that shows how organizations often introduce Product and related functions in an Agile environment. Of course, not everyone will follow this pattern: the sequence may change or some may jump straight into later stages, but the main progressions is typically similar.
The starting point often looks like this:
“IT”/Technology is developing and operating software applications. Agile Product Owners (POs) exist, but they are typically part of the technology organization and often have less of a true Product background, but tend to have job titles like Business Analyst, etc.
As the organization doubles down on making the software products actual commercial products
and is ready to start emphasizing product as an actual craft and independent function of its own right, Product Management is introduced into the organization:
Planning ahead in software development – just enough
Big Design Up Front (BDUF) is dead. There may not be too much agreement about any one thing in software development, but the industry has pretty much concluded that BDUF doesn’t work.
As Agile practices and mindset took hold, up-front architecture was essentially looked down upon. And for good reason: in many cases, a system architecture can evolve and be adjusted over time as the system matures. We call this emergent design. (On the far side of the continuum of up-front planning, opposed to BDUF, lies “Just start coding”, which is still practiced quite a bit too, with varying degrees of success as it is more the extreme case, but may be sufficient in simple cases.)
Another mantra circulating in Agile circles is to focus on and start with the easiest thing that can possibly work. This approach allows us to focus on solving the immediate problem at hand while ensuring we are not pursuing an overly complex solution. The theory is that – with the help of emergent design – the implementation can be adjusted down the line.
However, as organizations scaled their development teams and systems grew more complex, problems started to surface. It became problematic for several teams working on the same large solution to let design simply “emerge” in real-time, at the team level. After all, an application architecture is not fully malleable and might be resistant to change. And several teams working on the same application require coordination, agreement on architectural approach and at least some level of planning. A more intentional architecture was needed, without resorting back to the BDUF days. And therein lies the key, which is more art than science: finding the sweet spot between emergent design and intentional architecture (see Agile architecture).