Articles, Product Management, Stakeholders

Being Right is Not Enough

This article was originally published in Product Management Insider on Medium.

“This isn’t what we asked for,” the director said, indignance in his voice. “They have to fix this. I want our team to make a list of all the changes we need.”

I was sitting in a conference room, discussing the state of a million dollar software project which had just been delivered for acceptance testing. The project had started with hundreds of pages of documentation, followed by nearly a year of “on track” status updates. Once we could finally test the software, the director was livid to see that it didn’t match his vision. And he wanted his team (a team of environmental engineers, not designers) to redesign it — after it had been built and the budget was nearly spent. Talk about scope creep!

I tried to tell the director, the assistant director, the contract manager — anyone really — that this was a bad idea. We should get it in front of real users first, I argued. But no one wanted to listen to me. Instead, the director put other associates on the task of building their own wireframes from scratch. They spent endless hours on learning to use wireframe software and creating new designs, which resulted in change agreements and more money spent. And did I mention that this was a government project? These were taxpayer dollars!

The first time I tried to convince a boss to change his mind, it went something like this.

I started looking for a new job not long after that.

I also did a lot of soul-searching. I had learned through years of academic achievement that being correct was what mattered. This experience brought home for me something I now tell product managers regularly:

It’s not enough to be right. You also have to be persuasive.

But how? What if I told you that I’ve been testing and refining a step by step process for driving evidence-based product decisions that set products and product managers up for successful growth?

You might not believe me. So I’d like to tell you another story.

This one takes place years later. I’d just joined Shutterstock as the product manager for Skillfeed, an online education platform. As I asked more of my new colleagues for their perspectives, I discovered that before I was hired, some of them had argued, unsuccessfully, for shutting it down — and they may have been right to do so. But they hadn’t been persuasive.

If I approached this the same way, I would have failed this time too. So I had to do something different. I had to put energy towards not just the problem, but also the people around the problem.

Do you focus on the problem, or the people?

It was a slow and gradual process. I started with empathy for the decision makers. I put myself in their shoes and learned as much as I could about why they supported this project, what they thought it could do for them and the company, and what objections they had when others had tried to change their mind. I went out and gathered evidence, shared new insights, and asked follow-ups. I didn’t deliver fully-baked thoughts to them from on high; I guided their thinking, let them develop their own thoughts, come to their own conclusions, and convince themselves.

By doing that, I ultimately did something no one else had. I persuaded the billionaire CEO of a public company to kill his pet project.

Since then I’ve found that while the specifics won’t transfer to every new situation, there is a core process to it that will — a process that has worked dozens of times to lead to product and career growth for my teams and clients.

I can’t claim that I’ve never failed to bring others along with my vision and strategy, because I have learned these skills the hard way. But what I can do is tell you what went wrong, what I tried differently the next time, and what challenges to expect along the way.

I want to share what I’ve learned with you so that you can set yourself up for career success. And the next time that you’re asked to execute a feature or product idea that you aren’t excited to add to your resume, you’ll know just what to do.

Discovery, Past Work, Product Opportunity Assessments, Stakeholders, Workshops

How to kill a bad idea workshop at Thoughtbot Summer Summit

Yesterday I had the pleasure of running a workshop at Thoughtbot‘s Summer Summit.

ThoughtbotThoughtbot is one of my favorite design and development shops, because they are creative, smart people who are great at applying modern best practices like design sprints, design thinking, agile, and extreme programming to build products for their clients. We used them when we were getting Shutterstock Editor going and they brought a lot of value to the team.

So I was thrilled to have the opportunity to talk with them about how to persuade key stakeholders to pivot or even kill an idea. We did exercises around about empathizing with stakeholders; quantifying the product opportunity; selecting key outcomes, core behaviors, and key metrics; and focusing research by talking about initiatives’ risks ahead of time.

It's not enough to be right. You also have to be persuasive. I’ll be expanding on this to offer a public workshop in October. Contact me or sign up for my newsletter if you want to be among the first to know when tickets are available!

Articles, Data Science, Product Management, Quotes, Stakeholders

How to kill a bad product idea on Alpha blog

I talked with Mike Fishbein about techniques to identify bad product ideas and convince stakeholders when it’s time to end an initiative. Here’s an excerpt:

When working on a product that’s already launched, Holly emphasized the importance of looking beyond “vanity metrics”, such as page views and user counts, to truly understand if the product is valuable to customers.

Read the full article on the Alpha blog for more insights, including advice from Tami Reiss and Beth Temple:

How do you kill a bad product idea?

Agile, Articles, Discovery, Method, Stakeholders

Product leaders, educate your stakeholders by adding this one thing to your sprints

This post originally appeared in Product Management Insider on Medium.

The BLP Demo helps user-focused discovery grow in both old and new organizations

Many product teams struggle to dedicate enough time and resources to discovery and experimentation amidst the pressure to ship new features. I’ve found that a key to developing continuous discovery and delivery practices— sometimes called dual-track agile — is to master the simple practice of hosting a “Built-Learned-Planning Demo” (BLP Demo).

In short, the BLP is a demonstration that gets integrated into your sprint cycle and emphasizes the value and takeaways from doing customer development.

It’s designed for your agile cadence and can help you nurture your user-focused practices to grow strong amongst the challenges of a growing company or the organizational inertia of a large organization.

How do you do a Built-Learned-Planning Demo?

A good BLP Demo includes three sections: what we built, what we learned, and what we’re planning. I’ll review each briefly.

What we built: Most teams already do this as part of their agile process. But in case your company’s sprint reviews need some new life, I suggest that teams pick a few of their most interesting developments and be sure to describe what user problem they were trying to solve in addition to what was built.

What we learned: This section can include updates from any team member. Engineers might describe results of a research spike or proof of concept prototype. Designers might share learnings such as usability test results or user interviews. Product managers might share product insights such as updates on the competition, new data on product usage, or results of customer discovery research. Having a place in the demo for updates from non-engineering roles also builds the team’s understanding of each other’s contributions, helping to develop a cohesive team of diverse perspectives.

What we’re planning: In this section, we share some things we’re planning, connecting it to our learnings. This might include architecture plans, UX designs, product or UX research, or roadmap updates. As we share next steps at the same cadence that our engineers deliver software, we build understanding of how product decisions are made and what valuable product discovery is happening. This also helps us develop trust with our stakeholders, so that they can attach to something other than a feature schedule.

Why is a Built-Learned-Planning demo a good way to drive change?

Because the principles behind the ceremonies used in agile software development can be used for agile discovery too. Even better, expanding familiar practices to include the agile discovery work can make these changes easier for agile development organizations to adopt. As Ken Rubin, author of Essential Scrum, explains it,

“The goal of the sprint review is to inspect and adapt the product that is being built.”

By covering not just what we built but also what we are planning, we are ensuring that both tracks of our dual-track agile software development are inspected and adapted regularly. By sharing what we learned and how we’ve updated our plans accordingly, we can keep our stakeholders up to date, coaching them to value learning as well as delivery and to trust our teams to decide their most impactful next steps. Over time, they will come to look forward to the insights as much or more than the demos of built software.

The Built-Learned-Planning Demo at work for the Shutterstock Editor team

For example, consider some highlights from a BLP Demo we did when I led the Workflow Group at Shutterstock.

The Shutterstock Editor team showed text outlining during the Built section of a BLP Demo

During the Built section, the Shutterstock Editor team showed the addition of the outline functionality for the text tool. Instead of just showing that we built an outline tool, we described the problem — when users add text on top of an image, it can be hard to read the text if the image has lots of color variation. Because we were developing iteratively, we wanted to develop the simplest solution. After exploring the feasibility of both outline and dropshadow effects, we started with the solution that we could get to market most quickly. After this explanation, our engineers demo’ed the outline functionality. Instead of getting a “that’s neat, but so what?” reaction, our stakeholders were able to understand what value the functionality delivered and why we’d chosen the scope that we did.

During the Learned section, one update was usage data on a feature over time, highlighting how the usage changed after we rolled out a UX update. Sharing lessons such as this on how a UX change drove increased usage of a feature helped to shift stakeholder’s conversations from output to outcomes.

For the Planning section, the workflow team, which was in charge of features on the core site that support and enable customer workflow, shared a high level look at ethnographic research plans to dive into the experiences of a target set of customers. This moved the conversation to how we would flesh out details on the initiatives we were exploring for future sprints and gave us a chance for early feedback on our plans.

These highlights of a BLP Demo from my time at Shutterstock illustrates how the simple practice of adding product discovery to the sprint review pushes the team and stakeholders to add a focus on measurable outcomes and lessons learned to the usual cycle of shipping code.

Get your own Built-Learned-Planning Demo started quickly

Here’s a template that I use to get a team started on these Built-Learned-Planning Demos. Feel free to copy and edit it for your own uses.

The three parts of the BLP Demo

If you are a team member, try working this into your team’s practice. If you are a leader, try putting support in place to encourage this on your teams, and hold them accountable to produce and share learnings every sprint. This will plant the seeds for your organization’s continuous discovery practice to grow.

At young companies, practicing this will help you scale without losing your customer focus. At existing companies, these teams can become the impetus for cultural change that drives innovation.

As with any process change, you need to try it for a few cycles and iterate to figure out what works best in your organization. Then please let me know how it’s working for you and what challenges you’ve encountered along the way!

Roadmaps, Stakeholders

Techniques for managing timelines on Tech Republic

I talked with Moira Alexander about using long term agile planning exercises to set teams up for success and communicating candidly with stakeholders to manage expectations.  Here’s an excerpt:

​When it comes to addressing expectations, Hester-Reilly says H2R Product Science focuses on regular communication with stakeholders about what’s known and unknown. She utilizes visuals to show the complexities in the problem and in the technology that her team builds. In the planning stage, Hester-Reilly walks her teams through a technique similar to agile planning poker, to improve work estimates. The goal is to help her teams identify various projects they’ve done and assign a value, then they look at the work planned and do a comparison.

Check out the full article on Tech Republic to learn more tips for scheduling large initiatives:

How to address project scheduling difficulties