Menu

“Why Not?” is a bad reason to ship a feature

I agree with Chris LoSacco that “Why Not?” is a dangerous questions to ask for any product team:

Often stakeholders assume that if their ideas aren’t bad, they should be on the roadmap. “This isn’t hard; let’s get it in front of the engineers.” But the burden of proof is the other way around — ideas should get turned down unless they clear a high hurdle.

Just because a feature is easy or obvious doesn’t mean you should build it. This is why I prefer the question “Why Now?”:

What is the danger of not doing this project right now? If we don’t solve this problem or add this feature right now, what do we lose? Are sign-ups going to drop? Are we going to lose customers? Are we going to miss a major shift in the market? If so, then, yes, now is a good time to work on it. But if the room suddenly falls silent and everyone comes up short on the downside of skipping over the idea, that’s a pretty good indication that it can wait for later.

Accountability, tripwires, and other product management lessons learned on a failed project

This is an incredibly brave and insightful post by Erin Chan that I think every product manager should read. In The Hard Thing About Complex Products & How I’ve Grown as a PM she describes a long, failed project at Shopify in detail, and what she learned. The section on creating “tripwires” for complex projects is something I’m going to start using immediately:

A tripwire is a mechanism or an indicator that you define, and when it gets triggered, flags are raised.

For example, you should set the tripwire of ‘time’ when a milestone isn’t completed after a defined period (for me, this should have been two months). When that happens, my recommendation is to have a serious discussion with the team and make your Leadership and stakeholders aware of what is happening. Communicate the changes that you will make to the team or process to get the project back on track. Next, outline what happens if the milestone isn’t completed in three months, then four. These are your tripwires as determined by time, but you can define tripwires in whatever form you see fit for your initiative.

What I look for in product management software

I’ve had this vague sense for a while that I need to dig into the product management software space a lot more. So on Friday I just did it — I signed up for a bunch of accounts and started playing around. As I went through each product I realized two things:

  1. I didn’t know what I was looking for.
  2. Most of the products I was looking at didn’t know why they wanted me to use it either. The landing pages are all great, but once I was in the product, it was like a different (and very confusing) world. Which is kind of ironic for a product that’s aimed at product managers.

So I took a step back and asked myself why I’m actually doing this. What are the issues I’m hoping to address with software? What am I looking for?

In short, I am looking for a better way to plan. JIRA is a great execution tool — I don’t want to change that part. But JIRA is a terrible planning tool. And our current process of using Basecamp and Dropbox Paper for planning works just ok for me. The combination lacks a bunch of things to make it as effective as it can be.

I then identified what I would need to feel like our planning and scheduling process is effective and efficient:

  • A visual, lightweight, flexible representation of our product ideas and overall strategy, to help us with prioritization.
  • Prioritization scoring (customer / business impact, effort, etc.). I’d like to try a version of RICE at some point, but it should be flexible enough to use whatever system we want.
  • Incorporating, summarizing, and linking customer feedback from a variety of sources. We currently do this in JIRA, and it’s not a great workflow.
  • A way to go from general idea to product specifics in an orderly and predictable fashion. Right now we use JIRA, Confluence, Dropbox Paper, and Basecamp, and that can get a little confusing.

This gave me the framework I needed to evaluate the different products I was looking at. I’m not done evaluating, but right now productboard is the one that seems to fit our particular culture and goals the best.

productboard overview

Here are the list of things productboard has going for it:

  • The one thing that makes it stand out from all the others is that it’s a flexible system rather than a process (see the overview diagram above). Instead of forcing a particular software development process, it has no opinion on the specific methodology you use to prioritize and get work done. It’s focused on letting you use your own way to gather customer insights, define business goals, and prioritize work.
  • It will let us gather all user insights together, and prioritize features based on our goals and objectives (or “drivers” in the productboard language).
  • It will let us easily share, communicate, and change the plan without getting too formal about it.
  • If we wanted to, we could have a public-facing portal to get feedback on ideas, like this.

Oh, and their Why productboard? page is pretty solid, especially this phrase:

a way that provides transparency, fosters collaboration, and encourages alignment with the broader product team.

I’m not done evaluating yet, and who knows where we’ll end up. But I thought I’d share my initial thoughts and explorations of this interesting meta-industry.

Software should be designed for teachability rather than learnability

Related to the podcast discussion I shared the other day, Andy J. Ko wrote a really good essay called The problem with “learnability” in human-computer interaction. He argues that most software is learned socially, not independently:

We just have to think about our own personal experiences to see that nearly everyone learns how to use all but the simplest software socially, not in isolation. Our friends and family introduce us to new software and teach us how to use it. Our parents call us and ask for help troubleshooting software behavior they don’t understand. Our children teach us about new apps.

He then goes on to ask what it would look like if we designed software for this kind of social learning:

What would it mean to design for teachability rather than learnability? It might mean supporting the creation of not just one tutorial, but a myriad of tutorials, each supporting learners with different prior knowledge and interests. It might mean software companies having their app’s splash screens start with the question, “How do you want to learn this app?” rather than dropping users to a home screen and giving them a few tooltips. It might mean designing software to have teacher modes, where someone could go through and annotate key parts of the interface for someone they are teaching how to use an application (e.g., “Dad, remember to always click this box this before you submit!”).

These are good questions to think about as we work on product onboarding strategies.

Podcast: why customer education should be a priority for all companies

I found this discussion on the Product Love podcast really interesting. Eric Boduch talks to Adam Avramescu (Head of Education at Checkr) about the importance of educating customers on how to use your product. They cover a bunch of topics, including the myth that you don’t need education if your UX is good enough, the right way to approach documentation, and how onboarding is an important part of customer education but not the only thing you need.

Listen on Soundcloud or Overcast.

Companies have to get better at explaining the data behind personal recommendations

Ryan Bigge makes some very good points in his post about better personalized recommendations through transparency and content design:

Data-driven companies know something that the user doesn’t. Yet the language used to convince people to act on recommendations lacks variety and explanatory power.

Algorithms aren’t neutral — or as Ryan puts it:

Every facet of machine learning is fueled by human judgement, so it must be multi-disciplinary.

Users are getting more skeptical about where these magical recommendations for what to watch, listen to, and buy come from. To establish and build trust, companies have to get better at explaining exactly why they’re recommending a specific product or action.

When it comes to adding new features, slow and steady is usually best

In the article From Four Wheels to Two RJ Marsan talks about the Lyft engineering team’s principles for quickly and safely adding major features to a mobile codebase. It’s full of interesting learnings as they went through the process of adding scooter rentals to the app. Here’s a good point about trying to avoid doing everything in the first release of a new feature:

Every new feature is a chance to start with a clean slate, and it’s often tempting to immediately build for scale. We all want our products to launch to massive fanfare and usage, but more often than not, the path to success for new features is slow and steady. With steady growth in mind, we designed our first architecture to support exactly what’s needed for our first product iteration, and nothing more. For Lyft Scooters, we cut out many features one might expect from a classic ride such as sharing ETA or setting a destination.

How to help teams focus, align, and start delivering at their potential

My favorite article of the week is one on change management, which, yes, I know how that sounds. Like you (probably), I hated the phrase “change management”. But in her article How to begin the invisible work of change management Cate Huston defines it as “taking teams that are struggling and helping them focus, align, and start delivering at their potential”, so now I finally understand what it is and I don’t hate the phrase any more.

Anyway, the entire article is excellent. If you’re interested in managing teams at all, you have to read this one. Here she is on diagnosing problems within teams:

Sometimes people look at teams and diagnose problems as an absence of process rather than an absence of values, or cohesion, or delivery.

And on the problem with trying to implement a process without understanding cultural context:

When teams struggle to do retrospectives, often the problem isn’t the lack of retrospective, but the lack of psychological safety that a productive retrospective requires. That might be due to lack of trust or cohesion on the team, or other problems that have not been addressed. You need to address those things first, otherwise the retrospectives will not be productive, and the process will be for naught.

More

  1. 1
  2. ...
  3. 46
  4. 47
  5. 48
  6. 49
  7. 50
  8. ...
  9. 201