Do you remember being taught how you should never start a sentence with “and” or “but” in primary school?
Over time, you likely realized the odd contradiction of using arbitrary synonyms like “however” to express the same meaning as “but” to start a totally legitimate sentence.
The reason teachers taught that rule was because “and” / “but” are frequently used as conjunctions to connect principle and supporting clauses (eg “today is sunny but also cold.”), so teachers were afraid kids may try to split the supporting clause into its own sentence (eg “But also cold”).
But, I notice many adults habitually substitute “and” or “but” with a larger synonym that has no semantic difference, for fear of breaking that long held rule.
This is a “rule” that was helpful in one context, but becomes unnecessary once you develop a nuanced understanding of why that rule was set in the first place.
In order words, there are “rules” to knowing when you should break the rules 1 .
A framework for rules
I’m considering “rules” as “generally accepted heuristics” that people adopt or teach to shortcut and standardize decision making. I find at best, many of these “rules” are applicable ~90% of the time.
In this framework, it makes sense why companies tend to develop more rules (eg process) when they grow. When they can no longer rely on individual heroics and skill at scale, they minimize the downside of inconsistent decision making by standardizing “rules”. If you are building on top of past success, having a ~90% hit rate is great!
Of course, there are individuals in the world who want that extra ~10% of correct decision making. For start-ups trying to displace large companies, betting on the last ~10% (without getting the other ~90% wrong) is what they have to do for a chance.
The rules I break (at work)
After some years, I’ve felt compelled to rethink several commonly taught “rules”, mostly in product management; though I think the concepts extend to anyone building tech products. Keep in mind, by my own definition, the rules that I occasionally break are still useful a lot of the time!
Rule #1: Product managers should be “problem-first”
Yuhki Yamashita, the CPO of Figma, has a really great talk about his reflections on design which covers this topic in far greater clarity.
In short:
The “rule” is that it is often considered sacrosanct in design to start with a problem statement before jumping into a solution (re: the double diamond method)
But the fact is, many product breakthroughs in reality were envisioned “solution-first”, not “problem-first”.
While solving individual problems may produce locally optimal iterations, it misses opportunities for step function change in the holistic experience; particularly when a paradigm shift is involved.
I encountered this around a year ago when I was tasked with automating my company’s customer reporting experience. I originally had a set of targeted projects, each mapped to a specific problem on the customer journey and a business goal of increasing efficiency or decreasing churn. When I went into product review, my CEO and CTO looked at it and basically said:
“Yeah that’s cool, but I think we should just build an AI agent for security teams to manage all their reporting needs =D”.
I was baffled by the end of that call, but with the benefit of hindsight and recent product success, I realized how my fixation on being “problem-first” totally missed the dots between how emerging technology2 could tackle multiple customers problems and business objectives in novel ways3.
Product managers are taught to think problem-first as a heuristic crutch to avoid building for no-one, or falling in love with their own solution. But being problem-first doesn’t necessarily mean you truly understand your users’ pain points or connect them to emerging trends.
The challenge is that most of the time, especially when people are iterating in a defined space, starting problem-first is a safe way to yield positive outcomes with low mental overhead. A problem-first position has the alluring benefit of always seeming somewhat defensible.
In contrast, being solution-first poses a classic “midwit meme” dilemma. It’s hard to know if someone who is operating solutions-first has a deeply empathetic (somewhat inarticulate) mental model of their users problems, or if they are just stubbornly proposing a solution that sounds cool.
Rule #2: Product teams should have clear timelines, before starting execution
After a few years experiencing wildly different team cultures and product launches, I’ve come to the belief that:
Every product / engineering leader ultimately faces a Pareto limit curve of execution “confidence” versus “velocity”.
Most “big” (and some times not big) company cultures naturally incentivize teams to optimize for confidence > velocity through processes
#2 is sub optimal for a few reasons…
Confidence > Velocity as “under promise and over deliver”
The saying “under promise and over deliver” is a classic manifestation of #2, where teams ensure greater confidence in their ability to deliver work on time by intentionally giving more conservative estimates.
Surprisingly, despite claims of conservative estimates, I rarely see the “over deliver” part materialize.
Early on in my career, I observed teams that would spend every quarter estimating every task down to units of half an engineering day. You may get a lot of perceived clarity on exact dates, but it also made engineers allergic to taking any extra scope, even simple UI polishes, for fear of slipping on (supposedly conservative) deadlines.
The premise of the saying is an unsatisfying middle ground as it boxes you into thinking you are stuck in a three-way tug of war between time, scope, and quality.
Quantitative factors like time, scope, and quality are frequently debated because anyone can look at numbers on a spreadsheet and play accounting magic to obtain a convincing output.
Furthermore, the entire process hinges on an implicit assumption in corporate: that every employee is modeled as a fungible and time-invariant resource. The tempting benefit is that you are able to predictably forecast work with measurable accuracy, but you give up a lot of potential optimizations from organizing specific individuals.
Velocity > Confidence as “work fills up the time you give it”
I don’t think this alternative saying is true at the extremes, but I’ve found plausible reasons for why it is a helpful way out of the unsatisfying middle ground.
At other times in my career, I’ve worked with teams that were not held under strict planning scrutiny, while still being empowered with the strategy and bought-in to hard external launch dates.
An obvious first-order consequence is that the teams spend less time “planning to precision” which means they have more time executing the roadmap and accomplishing more work.
A fairly apparent second-order consequence is that empowered teams will tend to be more motivated to hustle, recognizing that autonomy and low-process overhead is the reward of owning quality on-time outcomes. I would much rather work with a team that starts on a fuzzy timeline, if it means I know my Slack message asking an engineer to make small adjustments will have a culture of being finished in the sprint; and no one will make excuses that it needs to happen at the expense of a delay somewhere else.
The less obvious dynamic discovered: teams in this model can almost always “find an out” to launch something by a hard deadline which fits the spirit of the release milestone. As long as product managers and engineering teams are willing to go deep enough into the details, there is almost always a creative solution which gets you at least the 80/20 of your launch goals. If you trust that “out” exists, then debating the exact details of that feature before starting work becomes a pointless wasteful exercise.
What makes it hard?
While the notion of team empowerment and autonomy feels non-controversial, I rarely see this happen without a debate. Depending on culture and precedent, your stakeholders and leadership can be (understandably) livid at a (perceived) lack of clarity before the start of execution.
It is really hard to tell your go-to-market team or an executive, “hey, I have a way to get the same team to accomplish more scope at better quality in the same amount of time - I don’t know exactly how much more or exactly where we’ll end up right now, but it’ll be more - just trust me”.
Threading that needle to build and maintain external trust is critical to giving a team the space to operate autonomously. But if you manage it, I’ve found teams will almost always move far faster and at higher quality.
Rule #3: Product managers should be the central node of the team
While I think this analogy may have limited use for brand new product managers to build credibility, I generally find this mentality as long term counterproductive.
The responsibility of product management is far better represented as the architect of a system, not a critical cog within the system itself.
Many PMs may claim that they understand their role when framed this way, but I would argue from observation that most of their week to week calendars betray the truth.
Shreyas Doshi had an excellent episode on Lenny’s Podcast discussing one manifestation of this failure mode: constantly arduous planning cycles.
A common pattern in product management is spending multiple weeks per quarter doing regular planning; only for the inevitable mid-quarter changes that cause a flurry of ad hoc replanning and resulting loops of syncs, approvals, and dependency coordination.
This does not have to be normal! As Shreyas explains, they are symptoms of lacking a defined and well-articulated strategy.
But, it is far easier to treat the symptoms through replanning and re-coordination, than to fix the root cause of defining a strategy that everyone buys into.
Escalations outside of one’s control will always happen, but the difference in response hinges on a PM’s decision to view their responsibility as dampening external shock to their system, or architecting the system to be resilient itself.
When you have a robust strategy, it feels very easy to identify what escalations fit within of the scope and vision of your team, and justify which ones to push back against. If your team understands the strategy, a lot of adjustments you do make won’t feel like sharp pivots to them, but just rebalancing against the existing framework.
Naturally, some learning happens by necessity as product managers grow their scope, but depending on their steady state of work, it’s possible to plateau at a point that never forces someone to abandon that node mentality. They can pull-off heroics that put out replanning fires quarter over quarter and chalk it up to “the way things always are”.
So where do we go from here
To reiterate, by my own definition, I am saying these rules are still useful most of the time! But I personally find those nuanced realizations have given me far greater peace of mind at greater scope and impact.
Admittedly, work examples are easier to identify because decisions have shorter feedback loops to connect cause with effect.
But over the years, I’ve certainly re-evaluated and found plenty of value in reflecting on “rules” that are often taken for granted in life too.
However, that will have to wait for another Substack :) .
Definitely borrowing from Chesterton’s Fence in this piece.
This conversation took place long before Open AI popularized Deep Research.
In fairness, not being the CEO / CTO carries some incentive towards proposing more incremental solutions, but I still think at the time, I was extremely anchored on problem-first frameworks.
To varying effectiveness, teams set up weekly sprints, story point estimation, work back plans, and OKRs, with the goal to increase predictive accuracy on such timelines.
That it to say, product velocity in service of a thesis that the team believes will help their users; not directionless busy work.