What are you dividing? What are you conquering?

A colleague recently advised that we should “divide and conquer” on a body of work. She meant one of us should do one thing, and another of us should do another thing, and thereby we would efficiently execute separate steps necessary to complete the larger initiative. This colleague is a strong, experienced leader, and she wasn’t wrong to suggest this strategy. And of course, “divide and conquer” is a common English idiomatic phrase, used often in business and technology contexts.

But I think she misused the phrase — in a way that’s common in business, and that may be harmful to effective product teams.

Divide and Conquer (Latin: divide et impera, or “divide and rule”) is a concept from classic military and political tactics. Its origins are unclear, but it seems to be pithy advice for taking on a challenging opponent that has been offered by some of history’s most well-known leaders, including Philip II of Macedon, Julius Caesar, and Napoleon.

In my colleague’s directive, she was suggesting that we, the work group, split up. “Joey, you do this, while Tariq does that, and I will do this other thing.”

But divide and conquer, used accurately, advises exactly the opposite. The central idea behind a “divide and conquer” tactic is to split the foe, not our own force. We remain united; our adversary gets divided.

This is instructive for product teams. When faced with a challenge, don’t immediately send different people off to pursue different sub-problems, where they might get distracted, overwhelmed, or thrown off course.

Instead, divide your work. Break that challenge into smaller pieces that your team can attack with collaboration and unity. Critically, keep your team together. For example, to divide and conquer on an e-commerce system, empower a designer, an engineer, and a product manager to decompose the idea into components and work together on the highest priority subproblems. That’s how dividing can really lead to conquering.

On to the garden,

Contest! Subscribe to Win Goodness

The Pollinator’s publisher, SDG, is running a promotion in conjunction with a recent product and tech conference we sponsor, Open Source North.

Anyone who subscribes to the Pollinator in June 2024 will be automatically entered in a contest to win some sweet SDG and Pollinator merch, including a selection of local artisanal honey. If you aren’t yet a subscriber to this product-centered and bee-themed rag: please subscribe. If you are already a subscriber: please share with someone who might enjoy it.

Because sharing is what pollinators do.

Around the Garden

Pure or Traditional: a useful binary division of product orgs

Check it out: Product-led challenges: Organization and Leadership, Anne Steiner, Nerd/Noir

Here at Solution Design Group (SDG), our customer base comprises many companies whose history pre-dates the commercial internet or even the computer as a business machine. Many Pollinator readers represent such businesses.

These organizations have built products, systems, and markets over many decades. And while they are quite sophisticated users and builders of digital systems, their digital systems have always been shaped by their history and their non-digital products (services, manufactured goods, etc.).

We’ve always been a little inconsistent in our descriptions of such businesses. It’s far easier to understand software product at companies that sell software. But what about the financial services organization or agricultural equipment manufacturer or university who is now building software (websites, apps) to fulfill a mission they’ve been working on for a century? Are they software product companies? To discuss these companies, I’ve always used clumsy words and phrases like “pre-digital” companies, “physical product” organizations, or “software solutions for companies that aren’t historically software companies.” None of this language has ever felt particularly satisfying.

This recent newsletter from Nerd/Noir, a product consulting firm, helped clarify my own vocabulary and thinking about this. Nerd/Noir’s Anne Steiner advises that we might think broadly of two types of product organizations: pure product companies and traditional product companies. The notion of “pure product companies” neatly defines, by contrast, the “dark matter” of software made by all the other companies — which benefit greatly from good product practices and teams. I especially appreciate how Steiner locates the difference in financial and funding terms, like this:

If you’re one of the many Pollinator readers who is advancing product strategy and design in one of these traditional product organizations, check out Steiner’s article and newsletter. You just might see yourself in it.

Reconciling data and design domains

Check it out: The Looking Glass: The Paradoxes of Data, Julie Zhou 

Way back in the 1990s, when I was young and silly and building a career involving digital products and the World Wide Web, I read a book called Machine Beauty: Elegance and the Heart of Technology, by Yale computer scientist David Gelernter. It’s an extended argument for beauty and art as essential elements of effective technical and scientific systems. A sentence I’ll never forget:

With that perspective I encountered this thoughtful recent article by Julie Zhou, a well-known product and design executive. Zhou is formerly a VP of Product Design at Facebook, and now she’s an entrepreneur building an analytics platform called Sundial.so. Zhou is an imaginative writer and thinker, and she nimbly bounces between framing broad concepts and detailing well-chosen examples.

Like Gelernter 25 years ago, Zhou suggests that the disciplines of data (including science, engineering, quantification) and design (including research, vision, exploration) are far closer in spirit and in purpose than we often think. She applies this insight to her own career and to the careers of anyone with a design or product sensibility who is using data to make better decisions and products.

The bulk of her essay is a “Manifesto for the Data-informed,” where she enumerates five values that design-oriented, data-informed product pros should embrace:

1. Conviction around a purpose rather than searching for meaning in numbers.

2. Setting verifiable goals rather than vague aspirations.

3. Company-wide familiarity with metrics rather than outsourcing to “data people.”

4. Active testing of beliefs rather than seeking support for intuition.

5. Accepting probabilities rather than thinking in absolutes.

Throughout, Zhou relentlessly pursues her memorable thesis:

That’s a quote I’ll happily commit to memory. I’ll probably stash it next to Gelernter’s leafy canopy.

Subdividing a product management career

Check it out: The Growing Specialization of Product Management, Reforge.

I’m not sure I agree with the article’s opening supposition that there aren’t any codified specializations in product management. (Why say something doesn’t exist and then do such a nice job of describing how it exists?). But the bulk of the article is a helpful taxonomy of the ways product management roles and career paths might fit a few core specializations: Core PM, Growth PM, Platform PM, and Innovation PM. (Note: in this Reforge piece, as in most resources we recommend at the Pollinator, PM stands for Product Manager, not Project Manager.)

These four product management specializations correlate to four types of product work: feature work, growth work, scaling work, and PMF (product-market fit) expansion work.

It’s a good framework for leaders organizing a product team, or for practitioners pursing a product management career. And once you’ve absorbed all the concepts, examples, and arguments that Reforge lays out here? Well, there’s a part 2.

You best Shape Up, ya hear?

Check it out: ShapeUp and Once, 37Signals.

Last week a loyal Pollinator reader asked what we think about the Shape Up methodology from 37Signals, as well as about the post-SaaS business model they are pursuing with their new Once service offering.

37Signals is the firm behind the venerable collaboration tool Basecamp, as well as other business productivity applications like Hey! email. Their principal, Jason Fried, and his colleagues have been thought leaders in digital product design and workplace culture and practices.

In 2021, 37Signals published this great e-book that outlines their methodology, which they call Shape Up. Shape Up specifies six-week build cycles followed by two-week cooldown periods, and it starts with a “shaping” stage of ideation, sketching, and rough framing and documentation.

Shape Up: what we like

• Structured Timeframes: Six-week cycles with two-week cooldowns are a clear, consistent rhythm for planning, work, and reflection.

• The “Shape” stage: The shaping work is the best part of the Shape Up methodology, in our opinion. It helps define problems and solutions upfront, reducing scope creep and enhancing clarity.

• Team Autonomy: Pollinators dig team empowerment, which fosters accountability, motivation, and productivity.

• Focus on Quality: We suspect shaping at the right level of detail and bounded projects can lead to higher-quality products and better outcomes.

• Balanced Workload: The cooldown period allows time for addressing minor tasks and planning the next work — plus it limits burnout.

• Bets. Risk is managed by framing work as bets on the outcomes that will be produced. Measure and invest accordingly.

Shape Up: what to watch out for

• Rigid Timelines: Yeah, I know we said we like the timelines. But the cycle may be too short for complex projects and too long for simpler ones.

• High Upfront Effort: Significant time and expertise are needed for the shaping process. That could be challenging for smaller or less experienced teams.

• May be tough for teams to adopt. We think this can be overcome, but high autonomy requires well-functioning, experienced teams; less experienced teams might struggle.

In general, we like Shape Up’s principles and methods, and we encourage product teams to try it.

As for Once?

Once is a new service model from 37Signals. Unlike the subscription model that exploded with SaaS (software-as-a-service) products, Once allows customers to purchase, own, and configure software as they go. We’ll see how the market responds, but their thesis is sound. We like their tactic of marketing directly to IT organizations that are eager to regain control of things they have lost.

In general, we admire when companies don’t just innovate by adding features or improving UX, but by rethinking their core business model.

Also: we love getting questions from our garden of readers. If there’s something you want us to opine on, email the editor. We’re not shy about pontificating.

Outside the Box

The Poetry Foundation’s Poem of the Day is a great way for closeted literary dorks to satisfy your yen for the written arts. Supply your email address and every day you’ll receive a new poem in your inbox. Selections run the gamut from contemporary to classics.

Attentive readers might hunt for Pollinator-themed poems, including well-known examples from Emily Dickinson (“to make a prairie it takes one clover, and a bee”) or Yeats (“Nine bean-rows will I have there, a hive for the honey-bee / And live alone in the bee-loud glade”), or lesser-known selections like “…Bee” from a poet named Eric Gansworth (“Pollination trails are smaller than those I’m forced to fly in, and lying in Little Rock, Santa Fe, Manhattan, Minneapolis, Seattle hotel rooms, the ellipse of your name trail winds me home, waiting, dusted in pollen and history.”)

Check it out at https://www.poetryfoundation.org/poems/poem-of-the-day

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.