Accelerated Context and the Validation Sparring Partner

​Dear Reader,​

Most of the AI conversation in product management right now is either describing doomsday scenarios, exaggerated improvements, or warning about what might go wrong.

But I am more interested in what changes for product teams doing real work. When a product team adopts an AI tool, what specifically changes about their day? What benefit do they keep coming back for, and what does that tell us about where the craft is heading?

Through the Productboard team, I heard about their Spark product, so I asked to speak with one of their customers about what changed in how they work, and what didn't, and turn it into real-life insights for you.

To be clear: this is not a sponsored post. Productboard did not ask me to write it, and no money changed hands. They just facilitated the contact to one of their customers.

I sat down with Jason, a digital product manager at March of Dimes Canada, a nonprofit serving Canadians with disabilities. He runs a digital skills training platform with a team of two, one developer and one designer, and he is the only product manager. Over the past few months, he has started using Productboard Spark, and this is what has stuck with me about its impact.

Yes, there are obvious benefits to the pure speed of development preparation, such as user story generation being roughly 40% faster and the team spending about a quarter less time on backlog refinement.

As with many AI benefits, the big question is what teams do with their freed-up time.

With Spark, Jason added a step instead of removing one. He still takes in stakeholder requests in Jira, but before he writes the story, he moves to Spark to pressure-test the idea. He has a conversation about it. What else can we glean from this, how should we approach execution, is this even viable. Only then does a development-ready story come out the other side.

So his time savings did not go back into shipping faster. They added a deliberate validation step that had not existed before, so he could be more rigorous about which ideas earn a story at all.

Accelerated Context

Jason calls the first one accelerated context. Spark preserves the context of his work, so he doesn't rebuild context from scratch every time he approaches a new challenge. Once that context is set, almost any task in the tool gets easier. For a team with a lot of history, the real question is how quickly you can bring a person, an artifact, or a routine back up to speed.

Validation Sparring Partner

He calls the second a validation sparring partner. Jason is the only PM on his team, with no room full of peers to think out loud with, so he has that conversation with the tool. He doesn't ask Spark what to do, but asks for critical pushback before decisions. Continuity and that sparring (instead of just speed) are what keep him coming back.

Jason had already used Copilot, and it was good enough to draft a story. But the question every PM will face is when the good-enough generalist stops being good enough to justify something more specific. You can get far in a spreadsheet before you need a database. His answer was specificity: the generalist gave him output he had to tweak with his domain knowledge, while the more specific tool, fed his real product context, gave him something he could use more quickly.

That gap shows up most clearly around accessibility. His users have specific needs, and a platform serving people with disabilities cannot optimize for what is easiest or most common, so his own knowledge of his users overrides generic LLM output.

Jason named the two human elements he sees as indispensable:

1. Connecting with users to understand their needs

2. Making the final call.

Spark is a good starting point and a good pressure test. It is not the decision maker.

The first wave of AI in product was about generating output, which you then cleaned up after. What Jason describes is a different move: a tool that holds your context and spars with your thinking, so the time you save goes back into judgment instead of more output.

The PMs who get the most from these tools will not be the ones who generate the most. They will be the ones who put the saved capacity back into the work the tool cannot do, validating harder and staying close to the users it will never talk to.

Thank you for Practicing Product,

​Tim​

If you consume one thing this week, make it this...

The Product Death Cycle (AI Version) Read it here

Who is Tim Herbig?

As a Product Management Coach, I guide Product Teams to measure the real progress of their evidence-informed decisions.

I focus on better practices to connect the dots of Product Strategy, Product OKRs, and Product Discovery.