Pollen, product, and planning

May is a favorite month here at Pollinator Worldwide Editorial Headquarters. Pollinating insects and birds emerge, gardens bloom, and the world is faintly redolent of lilac and clover. May is a month for bees, and for software product consultants.

One of the great joys of consulting for Solution Design Group is that we serve companies, software teams, and product professionals across a broad spectrum of sizes, histories, and industries. We’ve worked with major multinational corporations, world-class universities, mission-driven non-profits, and smaller companies who are just getting started on a product journey. In every interaction with customers or colleagues, we learn something valuable, which we then bring to the next interaction, and then to the next, so that the garden blooms.

From one customer we learn to explore a hidden audience, whose expectations may contradict the primary user’s. Another team teaches us that geographic location can have a sizable effect on a user’s experience. A company working on a manufacturing system problem reminds us that a financial services app might actually be a good analogue for the system their users need. All are insights worth remembering and sharing.

Products, teams, and markets comprise a complex ecology, featuring genuine chaos that confounds all prediction, like unexpected rain. When plans start to crumble and weeds emerge, or when the uniqueness of our market and value prop means we need to swerve in an unexpected direction, we return to bedrock principles of product work. Stay stubborn on your vision. Spend time with your customers. Simplify your priorities. Resist false certainty. Measure to learn. Empower a team to be accountable.

It’s easy to fall in love with our plans, but plans can go awry. That’s when it’s most important to stay true to your mission and bolster your product team. Because a product is how a company puts its mission into the world.

On to the Garden,

Around the Garden

Saying “no” with grace and optimism

Check it out: The Art of Saying No, Product Leadership Edition, Petra Wille

German product coach Petra Wille works with product leaders worldwide to improve their skill and value. In this recent post on her professional blog (www.petra-wille.com), Wille advises that a critical skill for product managers is saying no to executives, stakeholders, and even customers. This can be a serious challenge for product folk, who by nature may be yes-sayers.

The key: root your no in the needs of your customers and business and in the strategic purpose of your product. Wille does this by offering nine brief, practical sample scripts for situations where you might need to say no. For example, here’s her script for saying no when the new idea might contribute to feature creep or an unfocused product.

Good stuff, huh? The entire post is a handy, applicable resource that wise product pros will keep in their toolkits.

A cartoon primer on artificial intelligence

Check it out: Generative AI in a Nutshell - how to survive and thrive in the age of AI (video). Henrik Kniberg

This video from Henrik Kniberg (ex-Spotify, etc.) made the rounds on SDG’s internal AI-related Slack channel. It’s a relatively quick watch, and worth every minute. By the end you’ll be much smarter about Generative Artificial Intelligence (Gen AI). You might even be entertained.

Through animations and simple explanations, Kniberg explains the basic vocabulary, entities, and models for generative AI. There’s not much in the way of technical detail, but that’s not Kniberg’s purpose. He also makes a strong case for prompt engineering being an essential skill for the workforce of the future. (Pro tip: the smart business will be ready for this by hiring people with training and skill in dialectical inquiry and analytical writing.)

His animation is suitable for all range of geeks, but the curious non-geek is the ideal audience. I’ve shown this to non-technical friends and family curious about Gen AI, and they all get it, and appreciate it. The Pollinator community will as well.

On Dave Stewart’s The work beyond the work: a garden-side chat with SDG consultant Jared Johnson

Check it out: The Work is Never Just the Work, Dave Stewart

SDG Design and Product consultant Jared Johnson recommends this article from UK-based independent product designer Dave Stewart. Jared (JJ) chatted with The Pollinator about Stewart’s article and visualization. Here’s a condensed transcript of our discussion.

Pollinator: Jared, you have been touting this excellent article and diagram from UK-based product designer Dave Stewart. What struck you about Stewart’s post?

JJ: Well, Stewart highlights important aspects of product and design work that aren’t always considered when we’re estimating scope and time. These aspects apply to almost any craft or discipline. Stewart also identifies how visualizing the “work-work” itself vs. the steps preceding and following that work relates to the design and development process as a whole.

Pollinator: Yes. In Stewart’s post I see a common trap where we only count the time spent actively pushing pixels or coding a solution as “work.” Other necessary work of preparation, planning, communicating, etc. is forgotten in our planning — but that's where a lot of time is actually spent.

JJ: Exactly. And effectively preparing and understanding the work to be done isn’t negligible, no matter who does it. Finding alignment and executing work iteratively to meet mutually understood goals is crucial for success, and the “non-work work” to keep that train on the rails and moving in the same direction as product delivery and user expectations is very important.

Pollinator: Stewart’s piece also has important implications for planners. Often our colleagues involved in prioritizing, planning, scheduling, and funding (like project managers, workgroup leaders, or budget holders) are different than the product development practitioners. These planners reasonably want to estimate the time something will take, which of course translates to the cost of the work. A mistake planning leaders can make is assuming that these "non-work work" elements are a sign of inefficiency, or are extraneous. Stewart reminds us that it all "counts" as work. How can planners and practitioners avoid this trap and account for this work?

JJ: As Stewart outlines, the activities that take place “before, around, after, and between” the essential work of actually building the product or service can be as much as 80% more than the actual work itself. Stewart also proposes that “the ‘extra work’ increases proportionally to the complexity of the (execution of the) work”. To that point, between changes to the known scope of work, problems that can occur in executing that work—whether small or large—have the potential to drastically increase the planned scope of work—especially if the team is navigating unfamiliar, undefined, or complex dependencies or solutions.

I think collaborating to identify and visually depict these different parts of obvious work + hidden work (like Stewart's nice diagram) can be really helpful for expressing all that goes into “the work.” Just diagramming, up front, our total work helps all parties involved realistically evaluate everything that goes into our digital products. An exercise to visually lay out the work pre & post execution can better align expectations, dependencies, and direction everyone is heading in.

Pollinator: I also suspect good product, design, and agile methods can minimize this trap. Such methods don't prioritize matching estimates to actuals, but instead optimize an iterative, continuous value exchange that satisfies customers while building business outcomes like revenue, growth, retention. Planning and prep gets built in, and the team is “funded” based on the value it pursues and provides. Is that a pipe-dream?

JJ: I think it’s a dream worth holding if the team is organized, aligned, and mutually respectful. There’s a lot that goes into planning, preparing, building, changing, and supporting digital products and services. A product shouldn’t be blindly funded with no expectations or connective tissue back to the organization that deployed it. Instead we should support it with a mutual understanding that the team’s purpose is to iteratively deliver measurable value on behalf of the organization. That comes from a team empowered to discover and deliver, ideally with users involved to inform and validate. That’s how your “pipe-dream” could be a reality for almost any product team, and for the organizations that fund them.

Pollinator: Amen. Any final words of wisdom on Stewart’s article and the concepts we’ve discussed here?

JJ: This work falls into the messy-middle of product management and digital enablement decisions, and veers away from traditional UX practitioner work. Understanding everything that comprises a team’s work is necessary to elevate organizational maturity on delivering products and services. If we improve our ability to organize, understand, and involve all those potentially disparate skill sets and all their work activities, we’ll assemble a beautifully functioning orchestra, all playing the same music.

Those plans we make are just so adorable

Check it out: How to Overcome the Planning Fallacy, Clearer Thinking (Online mini-course)

SDG Consultant Kam Kubesh recently shared some provocative stats from a McKinsey and Oxford study about IT projects consistently exceeding their planned budget and timelines. Software projects run the highest risk of cost and schedule overruns, according to the study — on average exceeding their schedule by 33% and their budget by 66%.

When The Pollinator heard this — perhaps influenced by the discussion with Jared about non-work work — we thought immediately of the Planning Fallacy, a concept advanced by the late Daniel Kahneman, who won a Nobel prize for his pioneering work in behavioral economics. In a nutshell, “you suffer from the Planning Fallacy when you systematically underestimate the time or resource requirements of your projects” (Kahneman).

An Organization called clearerthinking.org recently released this free online mini-course that explains Kahneman’s work on the planning fallacy and helps you understand how to combat it. While it’s especially helpful for people involved in planning and leading complex work, like custom software development, Pollinator readers might even apply it to their personal projects, like creative efforts, home improvement projects, or side gigs.

The online course — which you can complete in about an hour — does a great job outlining contributors to our poor predictions, with many relevant examples. It also recognizes that the fallacy isn’t a problem of carelessness or inexperience. In fact, prediction errors often plague seasoned, talented people with deep experience managing massive projects

The course recommends a formal method for estimating effort by assembling a reference set of similar projects and calculating the median of those examples. But we love its suggestion for cases when you don’t have a good reference set. In such cases, this course advises, use your intuition and best guess to predict an estimate for a task — and then double this estimate.

Outside the Box

I came across this 2006 article from a New Zealand publication called the Rutherford Journal. The subject: the history of analogue computing. Analogue computers are devices that use mechanical principles and physical mechanisms to perform computational tasks. In the early days of computing, such devices were worthy competitors to the digital, electron-based devices on which you are no doubt reading this. Check it out at https://www.rutherfordjournal.org/article020106.html

About The Pollinator

• The Pollinator is a free publication from the Product practice at Solution Design Group (SDG). Each issue is a curated digest of noteworthy content and articles from across the internet’s vast product community.

• Solution Design Group (SDG) is an employee-owned digital product innovation and custom software development consultancy. Our team of over 200 consultants includes experienced software engineers, technical architects, user experience designers, and product and innovation strategists. We serve companies across industries to discover promising business opportunities, build high-quality technology solutions, and improve the effectiveness of digital product teams.

• The Pollinator's editor is Jason Scherschligt, SDG's Head of Product. Please direct complaints, suggestions, and especially praise to Jason at [email protected].

• Why The Pollinator? Jason often says that as he works with leaders and teams across companies and industries, he feels like a honeybee in a garden, spending time on one flower, moving to another, collecting experiences and insights, and distributing them like pollen, so an entire garden blooms. How lovely.