Product Management

The best product managers start in UX

by

ProductManager_UX_Venn

Some may find this controversial, disagree or just find it to be utter rubbish, but I believe, in the venn diagram of product management, it’s the background in user experience that truly makes the best product manager. I believe that in time, it will be UXers and UX designers or folks who came up through design that will eventually come to be the best product managers. You can have an understanding of the business. You can have an understanding of the IT. In both of those cases you’re removed from what the user are looking for and what they’re hoping to achieve with the product, and focused on the other facets of the respective discipline.

I also believe that there will be a time, when those designers have to tuck their design experience in their back pocket (design and UX thinking are likely second nature at this point or maybe that was just the case for me) and start to learn about the business and the technical aspects. This pivot is the thing that will leave some designers disinterested, some may even find it unsavory, and because of that I think that many designers will stick with their respective discipline of design, but for those who have that broad-ranging curiosity about all of the moving parts of their product I think it will be the UXer/designer that will be the discipline to lead product management.

Product Management is Product Thinking

by

usage_ux_product_thinking

John Cutler wrote a great article here: We Need Fewer Product Managers. — To a Product Manager, it’s a provocative, and maybe disturbing title, but I definitely get where he’s coming from.

He writes:

“…We need more product thinking, and less product managing.

You don’t need a product manager to:

  • “Get work done”, and keep the team focused
  • Manage projects, and give status updates
  • Manage a team, and advocate for the team
  • Have “accountability” for shipping features/projects
  • Facilitate standups, planning meetings, and retrospectives
  • Talk to customers and users
  • Measure the impact of work, and design experiments
  • Write user stories and requirements
  • Test work with customers and users

We have roles (hats) for these things: project managers, UX, researchers, data scientists, business analysts, team managers, coaches, etc. Do product managers often wear these hats? Sure. Do you need a product manager to wear these hats? No.”

John’s exactly right.

We have roles for these things, for these many and varied disciplines. Of course, especially in the beginning, there’s usually one evangelist wearing a lot of these hats, but as an organization matures towards a product-centric approach, the role typically known as the product manager, rather organically, becomes that of the product thinker. I’m confident that, in time, the natural evolution that brings together, seemingly disparate, disciplines like UX, IT and business needs will be thought of as a whole instead of separate parts. This is the natural outcome of truly undergoing a digital transformation. That evolution is happening, albeit slowly outside of software development organizations, but it is happening.

For web design – Use your backlog!

by

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

by

As far as web design in Lansing goes, I consider myself one of the most vocal advocates for user experience design. When I saw Ian Armstrong’s article on the evolution of UX, I was sure that other folks doing web design in Lansing would want to learn more –  Check out Ian’s article here. Additionally, I will add a few of my own points based on my reading of the article, but a full read is a must.

lean ux design lansing

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 the 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.

If you’re looking for web design in Lansing that puts your user’s experience at the center of their work, then get in touch today.