Pros and Cons: Deep Alignment for Your Team

A great way to make a decision your whole team can get behind: a Pros and Cons list.

Identify the folks that have a stake in, or a valuable add to, the topic at hand. (Could be: What feature do we build? Which ICP should we go after? Do we need a product owner right now?)

Get into a call. Book yourself and your team a solid two hours. Share a document in your video conf software or your projector. And just GO TO TOWN! Bullet list everything you and the team came up with - pros and cons. The decision will usually reveal itself, and everyone will have had a chance to weigh in. You'll be satisfied that you got the right data from the right brains. They'll be satisfied they got to weigh in, and see the reason for the decision in realtime. Share out the link after.

You'll have:

1. CLARITY
2. SPEED of execution
3. RECORD of your decisions that you can refer to later
4. HAPPINESS of your team

This is deep alignment. This is refinement. This is speed of execution.

If you want to see first-hand how effectively this can unlock and unblock your startup, DM me.

Startups Cannot Tolerate Toil

Startups absolutely cannot tolerate toil and hidden agendas of their teams. They cannot tolerate lack of direction.

They cannot build what has not been validated.

And they absolutely cannot lose track of what their engineering teams are doing.

If you're operating without some layer of transparency - standups, some refinement, some deep working sessions - all of which do everything but guarantee the clarity around where you're bleeding most of your money - it's gonna be a rough ride. Your engineering must return for you - to the greatest extent possible. And if it's not, you must find out why - as soon as possible.

I know because I've seen it over and over. Founder is looking for another raise or is intimidated by engineering, and takes their eye off the ball - and the product stays stuck. Investors get nervous. Customers churn.

You'd be surprised how common this incredibly difficult situation is.

One Founder + One Product Engineer

It's my personal experience that you can scale a product launch down to one founder and one product engineer. This is because the product-thinking occurs together with the founder in the room - in a working session. In this session you can sync deeply on what you want for the product - and what is technically feasible. What needs to be regarded as experimental, and what is doable right away. Keeping these expectations clear is tremendously gratifying for both founder and product engineer.

If a founder can temporarily sacrifice great design for a working, incremental prototype, they can learn more quickly what will work - ultimately, what is sellable.

The polish can and does come later.

Your working session is your refinement, is your sync up. It is both a satisfying and intense experience.

Feature Size and Risk

When you're getting a feature out on your platform, the size of that work is directly proportional with:

• the risk of it not going out in time
• the cost/opportunity cost being higher than expected (if you have variable costs involved)
• the feature having bugs and functional inaccuracies

There are ways to actually deal with this.

During product to engineering hand-off (a multifaceted topic itself), product and engineering can put their heads together to figure out how to bite off deliverable chunks of work. It does take some socratic back-and-forth, and the willingness to sit together in a room. But there is no replacement for the incredible feeling you get for shipping fast and accurate.

You'll be lowering more cortisol and delivering more value to your users than ever before.

A Completely New ICP

Imagine a completely new ICP. A completely new market. You want to serve them in some way - in the best way. And so you don't want to write (or...generate) a single line of code. Zero assumptions - just ridiculous amounts of PMF at the get-go.

The number one thing to do: outreach.

Enterprise AI Is Not a Thing

A question that might be on some of our minds: "We're looking for enterprise AI because our workload is growing and the team is already stretched." The problem with this statement is "enterprise AI". It is not a thing. The real thing is "what problems do we have [in our sales, operations, manufacturing or development workflows], and what is at our disposal now that could address them?"

Instead of just asking "Does AI really help?", do this:

Pick a giant wad of things that are either poorly automated or not automated. See if part or all of them can be automated now with AI. Build a proof of concept (lightweight, messy). Test it out. If it works, keep going.

The quick answer is YES absolutely there are efficiency gains but you have to search for them, qualify them, and test them (carefully...using...incrementalism).

Or you're just wasting time and money.

Treat Your Engineers Like UXR/Product

Treat your engineers like UXR/product and you get beautiful results.

What Is a Product Engineer?

The title is as it sounds.

It's taking a software engineer and pulling them left. What that means is that they're heading into Product territory.

Not necessarily all the way (this depends on the organization), but sometimes it does.

There are cases when this means having a stakeholder describe what they need their product to be, and have the product engineer engage in a dialectic with the stakeholder about what that could look like - perhaps offering possibilities to spur on the product thinking.

It is similar to a classic agile refinement, but does skip the step of having a design fully fleshed-out.

The same essential elements are at play:

1. a stakeholder with a vision or real, vetted requirements
2. a product person with knowledge of UX, prototyping, and the need for rapid feedback and iteration
3. the engineering knowledge to rapidly build the product

Sometimes there is more than one stakeholder. And sometimes there are more than one product engineers, perhaps with each engineer focusing on a different area of the product.

Both stakeholder and the product engineers are constantly angling for a deliverable: what is a minimal increment we can deliver? What did our lead or customer ask for? What can elicit the kind of feedback we need to get a 'yes' or a 'no'?

The result is a very lean, Agile-like process.

Real Agile Is About Efficiency

Real agile is about efficiency. So is problem discovery.

If you're going to burn time & money, you want to make sure you're doing it for a real reason.

If you're not quite sure the problem you're solving is real, ask your market.

If you're not quite sure you're solving it the right way, do it in small increments, and again, get your market involved (release in small increments).

To the furthest extent possible, shrink down your features (and therefore, your releases) to get feedback as fast as possible. This literally forces your product and your team to evolve. Every feature release is an MVP.

And of course, the working session is best way to get deep alignment on what that 'MVP feature' is.

Product and Engineering (if you're not the same person) - get in a room together and find that minimal set of functionality to get it out the door as efficiently as possible.

Feature Matrix Thrills

Even making a feature matrix, with features classified as either wedge or table-stakes/parity, is utterly thrilling. Feels like competitive sports.

You know what to build when you talk (and talk and talk) to your market. There is no guess work. No hoping. Just brutal value.

How Does the SaaS Organization Change in the Face of AI?

Do product and engineering become the same person, or the same team?

This will depend on company size and staff. Very small startups can and are rapidly changing from "the founder does discovery, the developer implements." With rapid prototyping, the founder can both "found" and build.

This works in smaller teams and smaller markets, because the surface area of customer discovery is still small. You are looking for a wedge or foothold, and are not yet concerned with market expansion.

However, as the surface area expands (along with go-to-market initiatives), specializations become more important. A product person doing customer interviews all day will perform better continuing to do customer interviews - or spending their late afternoon writing down user stories and contemplating how to synthesize solutions across many interviews.

Likewise, an engineer building will do very well continuing to build.

We must keep this in mind when making fair and efficient decisions in our hiring and in our role designations.

As always, aligning deeply with your team can give you the answers. Who is most capable of doing what role - and why? Does this lend itself to success in your current market, at your current size?

A product manager has grown the fine skills of detecting customer pain, of knowing how to elicit real issues in their market. We all understand the Mom Test, competitive intelligence, and JTBD. But it takes experience and focus to consistently deliver value in these fields. Just as well, an engineer is careful to detect when AI goes off the rails and builds a platform inconsistently (we all know its limitation in DRY code!).

This is exactly what I navigate as a fractional CTO - not just the tech decisions, but the people and role decisions that determine whether your org can actually execute.

Whether you're a service business building your first SaaS product or an existing team restructuring around AI, I help you answer: who does what, when do you specialize, and what are the trade-offs?

Spielberg Cursed Entrepreneurs

Spielberg cursed us with his magic and story-telling. I'm not talking about Disclosure. I'm talking about 1989 - his Field of Dreams movie. The whole thing is predicated on one, central, romantic approach to life: get inspired, build the thing, and you'll have people clamouring to use it.

This is actually kind of true - or true under certain circumstances (that SaaS idea that really lends itself to building in public, or posting on X). But this, again, a certain, specific type of product. And besides, PIB is marketing.

The sad thing is to toil in isolation for months or years to bring an idea to bear, only to hear crickets. Or to spend 20k on a build, not knowing if it'll work.

This is what we get for 'if you build it, they will come.' That, somehow, your creation will just generate a sort of gravity, and you'll get buyers, and scale to millions.

This also applies to service companies building an in-house solution, hoping to re-sell it. This is possible, and does happen with success on some occasions, but it's mere luck without a specific strategy.

This was my issue for years. Years! I even had a wise business consultant/coach tell me about the Lean Canvas. She had me write out the problem I was solving, the solution, key metrics, the unique value proposition. But back then, none of it landed for me. She was showing me the tip of the spear - the idea that your product or service idea is a hypothesis, and that there is an established way of treating it as such.

This has so many ramifications. Too many of us have gotten bit by the entrepreneurial bug, to have built it for months, or maybe years. The emotional momentum of the work means that to back up and think of your built solution as a hypothesis is…almost impossible. Many of us have gotten investors - friends and family, businesses or business peers - and are now saddled with obligations to these people, having never paused to think that the idea they built or are building is…a hypothesis.

To make matters worse, there really are many cases of coming up with an idea, implementing it, and somehow catching traction. These cases are extremely rare, but by virtue of their anomalous success, they signal to us that "if you build it, they will come" is the approach, rather than just being an anomaly.

The missing piece is to "get out of the building" (or pick up the phone). Talk to your target market. See what ails them. And build from there.

This relates very closely to incrementalism, which, when done correctly, effectively resembles agile.

An Engineer, a PM, and an LLM Walk Into a Bar

There would be some incredibly bizarre (or perhaps useful) software by 7pm.

Jokes aside, this comes from a statement Matt Peacock recently made, while describing the grill-me skill: "It should be you, the domain expert, and the AI in the same room."

Grill-me is bringing the engineer and the PM into alignment: it is facilitating the generation of and refinement of requirements.

This is the beauty of working sessions in general - tight alignment with all the necessary brains working together. It's almost a team sport.

The Best Relationship in Tech (Part 2)

Continuing on from my previous post about the best relationship in tech, and how it gets product to market fast and accurately - or stalls it completely.

The seasoned product manager knows about this dynamic. The seasoned engineering manager does as well. It's no surprise, then, that the PM must (in their minds) reach into the world of the EM, and the EM must reach into the world of the PM. What is at stake with a given initiative, presented by the PM to the EM? Does this new project keep an existing big account onboard? Is this the final tweak that will win us that first or third customer? Is this an idea handed down from the founder? Are we running out of funding and racing to market…for the fourth year in a row? Is there a solid set of requirements, further hammered into place by an elaborate, multi-week Figma design, or are the requirements loose and vaguely connected to a roadmap? All of these questions could be treated separately, and will be over time.

Product is doing a ton of work to figure out how to keep this SaaS afloat or how to bring in more customers. If they are not the founder themselves, their discovery work is critical to enable sales. They need engineering's support, not their friction. They need to know - is this idea or design doable, or does it involve a level of work that would be impossible to deliver in time to prevent that giant customer from churning? We can only hope the requirements come in small increments. But if they don't, can we devise a strategy to deliver them incrementally, offering glimmers of hope (in the form of traction and customers)?

There are specific, street-level conventions for dealing with literally every one of the questions posed here: technical feasibility, speed & accuracy of delivery, and so on.

Those conventions are: refinement and, in some cases, pre-refinement (the act of straightening out requirements such that, when the rubber does hit the road, the engine of delivery (engineering!), actually flies along, without getting mired in the mud of missing, ambiguous, or conflicting requirements.

At the end of the day, it's no surprise a mutually respectful, empathetic relationship wins here: it is a huge unlock for a SaaS business.

…And all of this presupposes an organization large enough to require separate product and engineering managers. There is of course an emergence of the most intimate possible relationship between EM and PM, thanks to AI: the Product Engineer. But that's another post.

One of the Best Relationships in Tech

A product manager (or more specifically, a product manager operating as a product owner, but that's another topic) has to interact with an engineering manager (EM) or tech lead. They could probably get away with avoiding each other - and often do.

If you were to look at this on a spectrum, the deeper the professional relationship, the better. And this has ontological reasons, not romantic ones. The product manager is deep in the world of people and business workflows. They are out in the fuzzy world of competitive analysis, customer discovery, user interviews (same thing), distilling workflows, trying to figure out the essence of a business problem or distilling various challenges into one or two core value propositions. (They are probably also playing support and scrum master, in many organizations. Is this fair? No, but that's another post).

This is as equally laborious as it is amazing.

Meanwhile, the engineering manager is generally grappling with various challenges around roadmap initiatives, engineer performance bottlenecks, plus at least a couple of nagging technical debt issues that occasionally bring down the platform at peak times, threatening his or her existence whenever someone decides to run a batch job off the side with API creds they shouldn't have.

The product manager lives and breathes the product. The engineering manager lives and breathes that which serves the product – the code, and probably the infrastructure it runs on (depending on organization size). These are very different worlds, but they must come into contact - often and at depth.

This is because the requirements distilled by product's lengthy analysis of the market and its users are indeed logical, but they meet the pavement, so to speak, at the moment of considering how to implement them (or retrofit them, into an existing product, already rife with its challenges - competing adjacent or parallel initiatives, technical debt, complexity, and team members that are there one minute and gone the next - for whatever reason.

As an organization, the synergy or compatibility between product and engineering will act as either a machine of efficiency or as a giant bottleneck.

Story Points

In a team of individuals where deliverable dates are pretty sensitive, story points can become pretty important; or they're at a minimum useful.

This is certainly controversial.

Unpointed tickets don't factor in the workload.

If you don't know the workload, it makes it much harder to deterministically say whether or not the ticket can be delivered in the available amount of time.

But storypoints have a really bad rap. Most people think they mean time estimates, but they don't. They mean effort (although in reality, that means it's a proxy for time).

I'll usually talk with my teams ahead of storypointing and take some time to philosophize on them for a bit. Figure out what the common consensus is. When everyone is contributing to the meaning of something, we can come to a common understanding - a common language. This helps in the next…hundreds of hours we spend together.

Get buy-in. Get deep understanding. Hear out the disagreements.

Well Thought-Out Tickets

Having really well thought-out tickets is a powerful lever in the speed of an engineering organization.

Developers can efficiently move forward in implementing features, rather than spending time tracking down information.

They don't spend cycles second-guessing what information they should probably know, and what knowledge is just missing.

This is also excellent for deadlines, because there is little to no loss of time spent on gathering information; all the engineer's time is instead spent on implementing - and with fewer mistakes in requirements.

The engineer is also less likely to task-switch, which is another significant speed boost: the authoritative source of information is the ticket, not random other sources (email, slack, Google Meet).

There is one incredible process that makes this possible: refinement. The exact process of refinement can vary, though, based on team maturity and dynamics.

Deep Focus and Non-AI Reading

I find myself intentionally searching for info from articles that are published prior to, you know, 2022. Maybe even before 2012. Heck, I even print them out to read them. This is the only way I know to achieve deep focus and not feel like I am simultaneously burning my eyes off. Gratifying.

Check out this purely non-AI sentence:

"Many an expectant mother has lamented the unflattering nature of maternity clothes and the boring stores that sell them."

That's an opener in the 19th paragraph. Yeehaw! You can see some culture and literature embedded in that.

Edwards, Janice. "Making Competitive Moves." Mastering Strategic Management, 1st Canadian ed., BCcampus.