For Web/Digital Product Managers – Your backlog is your best friend, use it!

Screen Shot 2018-04-11 at 8.18.27 AM(Graphic courtesy of of this deck from Reinhart De Lille)

 

Interesting article here by Guy Ligertwood – 11 Valuable Lessons I Learned While Working in the Real World of UX. The article, as a whole, got me thinking about the difficulties of agile, UX and specifically some thoughts around my early days of of backlog grooming and development.

Guy writes:

“Put it in the backlog and we’ll get back to it (never)”

 

Sadly, Guy’s not far from the mark. Frequently what goes into the backlog just doesn’t get revisited, mostly because it’s the non-priority, non-MVP (minimum viable product) options that get left behind (See the ‘Backlog Iceberg’ above). Movie editors will talk about losing parts of a story to the cutting room floor; Product manager’s lose stuff that isn’t a priority in the backlog. Backlogs are intended to be living and breathing documents that, especially during the critical start up phase, get much attention, but as market priorities shift, new products are released and organizational focuses evolve, older but not less useful backlog items get neglected. More than once, even right now as I type these lines, I can think of great functionality and features that didn’t make it into a releases I had hoped… the ones that got away… Well, maybe not ‘got away’ because as a Product Manager you have to hold on to those ideas, functionality and features for the right time.

Guy further writes:

“We hear lots about doing the best for the customer and in lots of cases we do, at first. The problem lies when we don’t get back to iterating on designs when delivering becomes more important…”

Again, Guy’s not wrong. As a product manager, you have to always be on your toes — Thinking, grooming and prepping the backlog, because iterations and sprints move quickly and they won’t wait for you. Nailing your cadence, watching the team’s velocity, negotiating stories, etc. are all the things that will keep you prepped and ready to hand off wishlist features and functionality that might not have made it into to early releases. If used consistently, the backlog can be the product manager’s best friend. If we’re doing our jobs as product manager’s well, there will be very few features that ‘got away’…

The Evolution of UX

usage_ux_process_methodolgy

Ian Armstrong has put together a fantastic article here called The Evolution of UX Process Methodology. I could try to paraphrase, but it’s too good, so I’m not even going to try. Check out Ian’s article. I will add a few of my own points based on my reading of the article, but a full read is a must.

Ian states that “in its purest form, UX Design is waterfall based.” These days, in most circles where folks are talking about UX, ‘waterfall’ is a dirty word that hearkens back to rigid PMBOK processes and exhaustingly long requirements gathering sessions, but Ian’s absolutely right. You have to get a sense of requirements, gather perspectives, mock things up, test out assumptions, wash, rinse, repeat. It’s waterfall. There’s no way around it.

Ian nails one of the key problems with being outcome based, what we work towards with agile vs. requirements based. This is a conundrum that many of have faced and still work to reconcile:  “Whereas classic UX is requirements based, Lean UX is outcome based… Designers found themselves under immense pressure to fill a sprint backlog before they really understood what they were building. As a result, a lot of development cycles got burned on features that never made it into the final product.”

So much development and rework lost trying to anticipate product needs… <sigh>

I’ve read a lot about Google Ventures Design Sprint, and attended a session at an O’Reilly Design conference where they talked about it, but even then, Ian’s explanation is as succinct and spot-on as any I’ve come across:

“Google Ventures conceived the design sprint, which allowed teams to rapidly define and test a low-fidelity prototypes. This jump-started the Lean UX cycle on emerging product teams and effectively eliminated the waste and rework problem.”

I’ll put a pin it there. Check out Ian’s original article.