It’s the time of year where leaders in all organizations are planning for next year, creating an Annual Operation Plan (AOP).

While these plans may not always unfold exactly as envisioned, they create a shared understanding among leaders and teams about key priorities for the coming year.

I recently facilitated a roundtable with several leaders about annual planning and distilled the discussion into an approach that is less painful and more fruitful.

After a reorg, my team inherited what we thought was an awesome product.

We had big name clients and a flashy demo that opened door after door for new prospective clients.

However, as we talked to current clients and looked into their use of the product (or lack thereof), it was clear this product was struggling.

As CTO and Head of Product, I worried about the 13th month.

After an initial 12 month subscription, we wanted our clients to sign up for that 13th month, to renew for another year.

At PowerReviews, we had 1,200 clients in 20 countries. Every month, one or more client’s one year subscriptions were coming up for renewal.

A panel of industry execs weighed in on how we can get exec backing for design and research activities.

We discussed the role of UX research, the importance of qualitative and quantitative data, and how to demonstrate the value of design to non-design senior leaders.

Many companies adopt the Objectives and Key Results (OKRs) framework.

They create goals but struggle to achieve them.

Only some of this failure can be blamed on the goals themselves.

Part of this failure can be attributed to a lack of an analytic culture and a lack of an analytic mindset in your key employees.

It’s a simple question.

But often there’s an unsatisfying answer.

The first step towards understanding whether you're successful today starts with recognizing (and using less of) the following types of data: “Anecdata”, Reactive measurements, and Internal metrics.

Teams are stuck in a "doom loop" of planning.

Every time there's an unpredictable event, leadership asks for more planning in order to avoid another unpredictable event.

Instead of continuing to predict the future (poorly), teams should repurpose longer term planning time for discovery time.

“Start somewhere, anywhere.”

The first Product Discovery effort for a team doesn’t have to be perfect.

Product leaders don’t have to be experts in Product Discovery to get their teams started doing Product Discovery.

Data analysts provide the eyes and ears for Product Leaders. A few simple tips can maximize this relationship.

Over the years, I've managed and helped grow the career of many analysts and data scientists.

As a coach, I facilitate most every session that I attend. The group size ranges from 3 to 100 people. These are some of my top techniques for getting the most out of individuals in a group setting.

Use these techniques to avoid groupthink and one-sided discussions.

Launching a product feels like success.

I've launched hundreds of features and products and that feeling never gets old.

Sending this newsletter feels like a launch, providing a mini rush of positive emotions.

But I know better than that.

Many Product teams only listen to users in the beginning of the product development process.

After this initial research, they build their solution but don’t test it as they create it.

This gap in interacting with users (sometimes lasting months) is the Product Discovery Valley of Death.

Is asking for an estimate the first time you talk to an engineer?

This is a sign that you’re engaging an engineer too late in the process.

Bringing an engineer into early conversations helps avoid rework and surprises, enable smarter trade offs, and encourage technology-based improvements and innovation.

Having a product that wins in the market is extremely satisfying. Trying to repeat the success is equally frustrating for many Product Leaders.

Often, Product Leaders succumb to a “success bias.”

Sounds strange but it happens all the time.

Most Product Leaders may not even know this is happening or may have inadvertently created a process where this happens.