I nodded along vigorously to Cap Watkins’s The Fight:

What I’ve come to realize in the past two years is how important it is to find a company and a product worth fighting for. To find a team that is dedicated to delivering the best product they can, despite the bumps, the frustrations, the exhausting moments along the way. Hurdles and failure are totally unavoidable. Having a resilient team around you working on a product you all believe in will make those hurdles easier to clear. They’ll turn failure into a learning opportunity. Great teams working on products they’re passionate about will back you up when you’re exhausted and cover for you when you’re frustrated.

When you find a team like this, hold on for dear life.

Allan White describes Our Product Design Process:

Our design process at HealthSparq is — just like everyone else’s — itself a work in process. We have ongoing debates about the tools and techniques we use to execute on each phase. Parts of our process (for example, a new pattern library that integrates directly with our apps) are being rebuilt and aren’t fully useful yet. It was very constructive to have this discussion, and to have a framework to build upon moving forward.

I’m posting this here because we started a design and development blog where we plan to share some of the things we learn as we go, and I think this one is particularly useful since it includes (what I think is) a really great visual of the design process we agreed on as a team. Head on over and check it out…

I really like the James Buckhouse explains in is article Story Map:

Halfway between a storyboard and a treasure map, it bundles the value and functional flow of your product with the delight people might feel at each step in your product. It sketches the UX flow without locking it down, and it delivers the gist of an idea and the emotional gestalt without prematurely belaboring the details.

A story map depicts how your product works and why it matters—but crucially—it does not explicitly spell out the final design, UI or in-the-weeds UX logic. It does, however, hold the product vision and works as a rubric against which the team can make better and faster decisions.

The article has some great examples worth looking at. As a big customer journey mapping fan, this is definitely something I want to try out.

I have one quibble though, and that’s with the name… “Story mapping” is already a very well established process in Agile development. Here are just a few articles about it:

• The new user story backlog is a map
• Visualizing Progress with Agile Storymapping
• Winnipeg Agilist: How to create a User Story Map

Semantics are important, so my suggestion would be to simply use a synonym:

@buckhouse Maybe just use a synonym and go with “narrative mapping”?

— Rian van der Merwe (@RianVDM) August 2, 2014

Some smart thoughts from Scott Sehlhorst in Classifying Market Problems:

Many teams struggle with backlogs or roadmaps which appear to be a collection of “a bunch of stuff.” Most teams try and address the problems that manifest from having a giant list of stuff by getting better at managing giant lists. This is treating the symptom, not the cause. If you’re trying to juggle hundreds of requirements, the problem isn’t that you have hundreds of requirements, the problem is that you don’t know why you have requirements.

Which reminds me of this cartoon, because that’s what happens when you get better at managing lists instead of getting better at figuring out how to make your product useful:

Of course, it’s also at this point that users tend to take matters into their own hands:

I don’t know if I’ve always wanted to write a book, but I do know that I’ve been writing the one I’m announcing today in my head for many, many years. It’s called Making It Right: Product Management For A Startup World, and it’s my attempt at putting together a practical framework for building great products:

The book came about because I saw a lot of people in organizations perform some of the activities that make up the role of product management. The problem is that very few people take a holistic view of the product, and this is not a role that should be split up into tiny pieces. So, you see marketing people doing some design and research, business analysts doing some spec writing, developers managing the product backlog, and so on.

All this without a person who is responsible for the overall vision, prioritization, and execution of the product. With this book I wanted to provide a complete product strategy that is agnostic to whatever development process people use (agile, etc.).

So here are a couple of links to check out more detail, if you’re interested:

• Smashing Magazine has a launch post up today.
• You can buy it directly from Smashing for $10 in their digital store.
• For the next couple of days, you’ll also be able to buy it for 99c on Amazon.

Smashing tells me that the Amazon thing, in particular, is important for the first couple of days after launch. So if you’re so inclined, please pick it up for 99c, and write a review. It will really, really help to give us a good launch.

Huge thanks to the Smashing Magazine team, and my technical editor Francisco Inchauste. They’re my heroes. And now I have to lie down.

Rich Mironov’s We Don’t Hire Product Owners Here is a treasure trove of advice and clear thinking on the dangers of not taking the Product Owner role seriously in companies that make the switch to Agile development. There are so many good sound bites, but I’ll stick with just one that hits close to home:

Don’t let your customer request list become your roadmap. Kano analysis teaches us that letting current customers prioritize your backlog for you leads to market failure.  Don’t let your product owners confuse “this is what the enhancement request says” with “understanding and solving real customer problems.”

Maiz Lulkin has a great overview of one of the most important and most misunderstood issues in software development in his post Technical debt 101:

In software development, the dreadful consequences of sacrificing quality are widely misunderstood by non technical managers. They underestimate how detrimental it is to continued productivity and morale, and ultimately, to the overall strategy of the company.

He goes on to explain why…

Cennydd Bowles writes about data-led design vs. idea-led design in Ideas and/or data:

Product design that’s driven entirely by data is horrible. It leads us down a familiar path: the 41 shades of blue, the death by 1000 cuts, the button whose only purpose is to make a metric arc upward. It’s soul-destroying for a designer. But its moderate counterpart, data-informed product design, is fine. It reduces risk, and encourages confidence and accountability.

Product design driven entirely by ideas is equally painful. The romantic notion of design genius and the Big Idea soon gets swamped by a culture of risk, favouritism, and blame. Idea-informed product design is fine. It provides agility, creativity, the power to see blindspots and seize opportunities.

Braden Kowitz makes a similar call for a middle-of-the-road approach in Should Tech Designers Go With Their Guts — Or the Data? For an extremely practical view of using data in design, check out Joshua Porter’s excellent talk from SXSW 2011 called Metrics Driven Design. And while we’re at it, here are a couple more recent posts about using data in the design process:

• Building websites with science
• The Agony and Ecstasy of Building with Data

Some truth from Joshua Porter in There is no later for your customers (my emphasis added):

There is no later for your customers. The only thing that matters is what they’re using right now. They don’t give a shit about your roadmap, your brilliant feature pipeline, or your vision of a better future. They’re trying to get work done right now and they only know what you’ve already delivered. So build a discipline around your launches, knowing that your ‘temporary, let’s get this out quickly and iterate later’ release is the current reality for your customers. Build up your attention to detail and force yourself to treat every launch like it is your final launch. Imagine that you’ll never be able to deploy something after this…have you done your best work?

Release early, release often is not an excuse to release crap…

The post I wrote this weekend on software development belief systems in corporate environments has been in my head for quite a while, I just hadn’t been able to write it up until yesterday. As often happens with these things, I noticed three articles in that past 24 hours that tie in really nicely with that post.

The first is Jeff Weiner’s Avoiding the Unintended Consequences of Casual Feedback, which talks about the kind of feedback executives should give to their teams:

Years ago, a former direct report of mine helped bring this point home. While he and his team welcomed my input, he observed that oftentimes what I thought was a take-it-or-leave-it remark would create a massively disruptive fire drill. Up until that moment, I had no idea my opinion was being weighted so heavily.

To address the issue and to ensure that the team and I were on the same page with regard to situations like that, we developed three categories to describe any feedback I provided (either in conversation or via email): One person’s opinion, strong suggestion, or mandate.

Next is Michael Lopp’s Chaotic Beautiful Snowflakes, which talks about the unintended work that managers often create without even knowing it:

The fact is that you significantly underestimate the amount of work that you generated this morning. You could document and communicate the obvious work, but you can’t document all the unexpected side effects of your actions. In a large population of people, it’s close to impossible for an individual to perceive and predict the first order consequences of their well-intentioned actions let alone the bizarre second order effects once those consequences get in the wild.

Finally, there’s John Maeda and Becky Bermont’s Building a Design Culture in an ‘End-Up’ Technology World, which talks about the elements of a good design culture in larger corporations:

In the end, building a great design culture is not the goal in and of itself. What it does is allow a company to recruit great designers, and then supports their ability to build great products, along with their counterparts in product and technology. Start-ups and end-ups may each think that they other has an easier time building or sustaining a design culture, but it takes work at any stage of the game.

All three articles are great companion pieces to what I wrote yesterday. I realized this morning that even though the traffic on yesterday’s post wasn’t huge, it will always be a personal favorite of mine, because it documents a lesson learned from a lot of sweat and frustration. And those are often the best lessons you can teach yourself.