“Promise me your next job will make every workday feel like a weekend hobby.”

My mom said that to me in the hospital a few days before she passed away, just over two years ago. It’s how she always described her own career. For nearly a decade, that’s how Slack felt to me. But it was time to build something new.

There was only one person I could imagine building a company with: Dolapo Falola, the most prolific and thoughtful engineering leader I’ve ever worked with. We’ve partnered since 2011, when we both left Google for Foursquare, and we reunited at Slack. We’d always said that if either of us started a company, we’d do it together.

Context constrained

The whole world was rushing to automate away tasks and jobs. But we wanted to build consumer-grade products to amplify what teams can do.

We narrowed in on the problem of team alignment, which was a big reason I joined Slack. Everyone said how much faster they were moving on their own with AI. But so few teams felt they were moving smarter together.

The cost of producing work was racing to zero. The hard part was the shared judgment, taste, and expertise that help a team figure out what to build. The frontier models are no longer intelligence bound. They’re context constrained. Agents are eager interns who lack the full picture. So they guess, confidently, by the token. The missing piece was the context people and agents need to stay aligned at this speed.

No two teams should think alike

Imagine a world where you never lose a great idea.

Where you never start from scratch. Or learn the same lesson twice.

Where new hires operate with the judgment of your most senior people.

Where your agents spend their tokens wisely on the first pass.

Imagine a world where no two teams think alike.

AI gives you the same answer your competitors got, averaged from the public internet. Just skim LinkedIn. But your team isn’t average. What makes it different: the unique lessons from customers, debates, decisions, and experiments.

That’s why we’re building Scuba, the shared context engine for teams and their agents. It’s the shared memory your team has been missing, so everyone stays aligned and can move faster together.

Capture anything, across apps, websites, devices, or directly. Keep the thought. The plan. The lesson. Share what matters, and put it to work in any tool.

How we build now

We started Scuba in the back half of last year. For the past six months, hundreds of early users have run on it in private beta. Teams built products and ran launches. Authors researched books. Founders explored markets. VCs made investments.

“Scuba allows me to feel really productive even when I know I’m being really lazy.”

“Scuba helps me feel like what I learn compounds instead of disappears.”

We turn scattered customer feedback into instant product fixes. It arrives as texts, Slack messages, call transcripts, and stray docs. I capture each one in a keystroke. When I save the onboarding call and the follow-up texts from a new user, a teammate’s agent ships the fix.

Our product development loop runs on shared context. Each milestone starts as a Collection of half-baked ideas. Scuba drafts product docs in one shot, so I’m an editor, not a first drafter. Our agents in Claude, Codex, and Cursor build from the same specs, eng plans, and customer feedback. We record our “soup tastings,” where we test prototypes together, and agents start fixing issues right away.

I’ve built software for two decades. Scuba and coding agents have reshaped how we do it. Tight alignment, loosely coupled execution. This post started in Scuba, too, with dozens of past captures plus a rough voice note.

Keeping my promise

If my mom were still here, I’d tell her every workday at Scuba feels like Saturday. I’m the only child of a single mom, so keeping my last promise to her means the world to me.

Work feels like a hobby when you’re in creative flow with your smartest friends. It’s work, without the cruft of a “job.”

Running on Scuba gives us an economy of motion without constant coordination. One person’s side thought becomes the next person’s big idea. Old lessons resurface right when we need them. We have under two hours of meetings a week, yet feel fully in sync. New hires ramp in hours, not months.

We’re lucky to build with a senior group who’ve mostly worked together before across Google, Slack, Meta, and hypergrowth startups.

With Scuba and our agents, our team of 10 has built like a team of 100. Your team can, too. Without the meetings, process, and misalignment that slow big orgs down.

Hello, world

We’re emerging from stealth with $34 million over two rounds. We’re grateful to Accel for leading our pre-seed and co-leading our seed with IVP, alongside BoxGroup, Conviction, Homebrew, and Scribble Ventures. Our angels include the founders of Slack, Instagram, Stripe, LinkedIn, Salesforce, Datadog, Vanta, Harvey, Dropbox, Abridge, Duolingo, Granola, Warp, Zynga, Groupon, Coda, Opendoor, and Flatiron Health.

We’re building Scuba for people who never want to lose a great idea. For companies that want to move smarter together. For teams with a mind of their own.

If that sounds like you, bring your own brain to scuba.app and apply for early access. We’re opening the limited beta to teams in waves.

Noah Weiss on Twitter

1/ It's nearly impossible to define what makes a PM great. They have diverse backgrounds, murky responsibilities, and wildly varied expectations across companies. That said, here's an inherently incomplete list of 10 areas great PMs excel at:

PMs have diverse backgrounds, murky responsibilities, and wildly varied expectations across companies. It’s nearly impossible to define what makes a PM great. With those caveats, here is an attempt at ten commonalities.

Great PMs live in the future and work backwards

They immerse themselves in research, feedback, data, discussions, and the market. They craft thoughtful, inspiring narratives for where the product should go — and the best path to get there.

Great PMs amplify their teams

They listen well. They infuse urgency. They foster collective creativity. They build consensus by default, but can drive hard decisions when they have to. They take blame and pass on praise.

Great PMs focus on impact

They constantly fine-tune product strategy to maximize business impact, so their teams never worry about whether their hard work will matter. They don’t care about accolades from peers, Apple design awards, or press write-ups.

Great PMs write well

They are succinct, structured, thorough, and persuasive.

Great PMs drive a fast pace of high-quality decisions

They make two-way door calls quickly, and help the org make one-way calls judiciously. They care about getting to the right decision, not whether they are right. They are the ultimate facilitator.

PMs should lay out well-researched tradeoffs, set timetables, and structure great discussions. Only in rare situations should they actually “make the call.”

Great PMs optimize for learning

They voraciously seek out insights about customer needs and pain points through research, experiments, and cross-functional partners. They course correct constantly.

Great PMs execute impeccably

They say what they’ll do, and then do what they say. Their follow-through is impeccable, and they don’t let details slip. When they join a team, quality and pace seems to dramatically improve overnight.

Great PMs apply product taste

They have a well honed sense of what a well crafted product experience feels like. They smartly balance quality with the demands of time and scope.

Great PMs exhibit data fluency

They define and track the key metrics that matter, and align the whole org around them. They know how to design and analyze solid experiments — and know when hill-climbing isn’t worth it.

Great PMs immerse themselves in the tech

Though they may not have CS degrees, they are effective collaborators and sounding boards for their engineering partners. They can help weigh complex technical tradeoffs and design decisions.

In summary: great PMs do whatever it takes to amplify their team’s impact on the customer experience and business.

Why is it so hard to incubate entirely new capabilities within mature products? A few strategy lessons distilled from the product histories of Instagram, Twitter, and Foursquare:

Original Tweetstorm:

Noah Weiss on Twitter

1/ Why is it so hard to incubate entirely new capabilities within mature products? It's a feature-level Innovator's Dilemma at play. A few strategy lessons distilled from product histories at Instagram, Twitter, and Foursquare:

Product Challenges at Scale

In the early days of a startup, you build as fast as possible to try to find product market fit before you run out of time and capital. By the time you get to scale with millions of users and hundreds of millions in revenue, the product development tradeoffs seem to invert.

At scale, even small product tweaks seem at risk of aggravating paying customers; big new features feel almost impossibly hard to bet on. The struggle to keep building innovative features come down to challenges like:

1. How can we make high upside, riskier bets while keeping stable a core product with hundreds of millions of users?
2. How do we optimize for learning with incremental experiments without frustrating all our users?
3. How do we justify building features that only a subset of customers will love without worrying whether everyone will like it — at least to start?

The Strategy: Incubate, Iterate, Integrate

There’s a three-part strategy dozens of tech companies have used to safely incubate new capabilities, iterate on them with real usage and, if successful, deeply integrate into the core experience to scale impact.

This feature laddering up approach sounds deceptively straightforward; in reality, it can take years of challenging work. When pulled off well, with hindsight it looks like the product evolution was inevitable.

• Incubate new features in a separate product space where they can provide value to a small subset of customers. The space needs to be inconspicuous to the majority but discoverable to the relevant minority.
• Iterate on the underlying functionality, algorithms, data, curation, etc. — powered by real usage — until it’s proven useful to a large portion of users. Disclaimer: this can take many years.
• Integrate the now high quality and de-risked feature prominently throughout the core product experience.

Learning from History: Instagram, Twitter, and Foursquare

These examples focus on building ML-driven features into existing products, because this is an even more complex challenge given uncertainty around data/algorithm quality.

Instagram

Instagram evolved from a “Popular” tab to a personalized photo feed:

• Incubate: Launches “Popular” tab in 2012 to surface photos from people you don’t follow for the first time, powered by a simple popularity algorithm.
• Iterate: Upgrades to “Explore tab” in 2014, powered by a collaborative filtering model to show photos from your extended network. Launches trending in 2015, personalized video collections in 2016, and so on.
• Integrate: After 4+ years of building ranking models, Instagram took the plunge to move to a ranked feed model powered by the Explore tab models. Later they continued to launch refinements like following hashtags to inject non-follower content into the feed.

Twitter

Twitter evolved from a “Discover” tab with globally popular tweets to a ranked timeline with personalized alerts:

• Incubate: Launches Discover tab in 2011 to surface popular tweets in your network.
• Iterate: For 5 years years, it refined the Discover personalization algorithms (2012), launched Moments (2015), and then merged search with the new Explore tab (2017). In parallel, it worked on personalized push notifications starting in 2013 with @MagicRecs.
• Integrate: Twitter launched its ranked timeline in 2016. Later that year, @MagicRecs graduated into a 100% feature for all-users. It continued to refine ranking into 2017.

Foursquare

Foursquare evolved from an “Explore” local search tab to dedicated discovery app with personalized, contextual notifications:

• Incubate: Launches Explore tab in 2011 to surface place recommendations based on where you and your friends have checked in.
• Iterate: For 4 years Foursquare refines its background location snapping technology to deliver personalized recommendations without checking in. Late in 2011 it launches Radar to do check-in reminders, Pilgrim in 2013 to alert people to interesting nearby places, and contextual travel recs in 2014.
• Integrate: Foursquare relaunches as a personalized recommendations app in 2014 — betting the whole company on tech where check-ins were no longer required. After continuous quality improvements, opens Pilgrim as an SDK (2017) to build a new core business line.

Summary

Beyond these examples, companies from Google to Spotify to Facebook have taken similar approach. It’s a reliable playbook for for building an entirely new feature (set) into a mature product: Incubate, Iterate, then Integrate.

Carve out the product space — and time — to take big swings and avoid the siren song of incrementalism.

After more than a decade working in product across Google, Foursquare, and Slack, I still often struggle to define the role of “product manager” (PM) succinctly. Explaining what makes a PM great is even harder.

Product Management isn’t an academic subject that one can study; most people learn by apprenticeship. They have diverse backgrounds, murky responsibilities, and wildly varied role definitions across companies. They typically sit at the intersection of development — design and engineering — and go-to-market — sales and marketing — where they research opportunities, guide strategy, and help take features from idea to launch.

It can be easy to romanticize product from afar. I’ve seen many people transition from another role to a job as a PM, only to feel disenchanted with the reality. Whether you want to become a PM, are a PM looking to grow, or work with PMs as peers, there are a number of dangerous myths about the role worth dispelling.

Noah Weiss on Twitter

1/ Product Management isn't a major one can study, few folks graduate into, and most people learn by apprenticeship. There are number of dangerous myths about what the PM role is. Here is a thread with five...

“PMs are mini CEOs”

This is admittedly a catchy tagline. But CEOs have direct management responsibilities, decision-making authority, business-level objective ownership, and often founder-level credibility for the original vision.

In reality, PMs have none of these. It’s a pernicious trap, because the PMs who act as if they are mini CEOs for a feature are the most likely candidates for a team organ rejection. Teammates want product leaders, not dictators.

“PMs are the decision makers”

Many people who convert from another role into product see it as step toward “making the calls”. It’s a common pattern, especially for disempowered engineers on dysfunctional product development teams.

PMs are responsible for the pace and quality of decision making. Full stop.

That does not, however, mean they should make even a small fraction of decisions themselves. They should be the ultimate facilitator: pulling the best ideas from their team, coordinating with cross-functional partners, and getting executive context.

PMs should lay out well-researched tradeoffs, set timetables, and structure great discussions.

Only in rare situations should they actually “make the call”. When they do, it withdraws from their organizational capital account balance. That needs constant deposits as a counterbalance.

“PMs are the idea generators”

More than any other product development role, PMs are judged nearly exclusively on the output of their team. Unlike engineers or designers, they produce few independent artifacts.

As a result, some PMs wind up viewing their ultimate work product as new ideas. They churn out 10x more concepts than their team could ever build.

This has a two-fold downside: their team execution suffers without sufficient PM attention, and it stifles the potential creativity of non-product teammates.

PMs do need to immerse themselves in context and research that helps their teams come up with great product ideas. Every hour in the field with customers is an hour well spent. In an ideal world, creative brainstorming is a constant team exercise that the PM just happens to drive.

“PMs have to be great at company politics”

Unfortunately, at the largest companies this one is a bit true. But at companies who have a few thousand employees or less, that degree of politics only happens when shared alignment breaks down.

Great PMs are an antidote to startup politics.

They keep disparate groups bought into a shared vision of where the company and its product need to head.

This requires developing deep domain knowledge, communicating compellingly, and setting an inspirational strategy.

“PMs need technical degrees”

While a technical foundation is certainly useful for PMs, like every hiring heuristic applied unconditionally as a filter, it produces far too many false negatives.

PMs do need to have a deep curiosity about the underlying technology behind their projects. They need to have some humility about the details, and the ability to develop strong partnerships with engineering.

What makes a Great PM, then?

Great PMs live in the future and work backwards, focus on customer and business impact, and amplify their teams. They drive high-quality decisions, optimize for learning, and execute impeccably. They have product design taste, data fluency, and technical acumen.

They didn’t study “product management” in college, because that major didn’t exist. They come from a wide diversity of backgrounds and relish wearing many hats. Though it’s nearly impossible to succinctly define what makes a PM great, you know it when you see a team they join make a step function leap in its pace of delivering impact.

“Chief Question Officer” is the unofficial role of many great product, design, and engineering leaders. 5 tips for asking better questions.

The best questions foster rigor, encourage focus, and teach instincts. Below are some favorites to try using when reviewing proposals for product plans or business strategy.

Adapted from this Tweet storm:

Noah Weiss on Twitter

1/ "Chief Question Officer" is the unofficial role of many great product, design, and eng leaders. The best questions foster rigor, encourage focus, and teach instincts. Some favorites when reviewing product proposals / plans / specs:

“What is the fastest path to learning?”

The biggest determinant to long-term product velocity is the pace of learning.
Learning is broader than just A/B experiments. How quickly are you developing new insights about customer needs and pain points?

Of course you need some mix of “earning” launches, ones you have high confidence will be a quick win for customers. But the “learning” launches are the ones that unlock future trajectory bending.

Judge PMs in the short-term on their pace of learning, and long-term on their impact.

Organizations that do the reverse perverse incentives towards short-term hill climbing.

“Are there any cheat codes?”

Put another way, in the classic scope vs. time vs. quality tradeoff: are there scope cuts we can make to speed up time while preserving quality?

There are many great types of product shipping cheats:

• Avoiding premature v1.1 polish
• Making scalable for only a subset of customers
• Smart defaults with fewer advanced settings
• Heuristics instead of complex algorithms
• Human curation to bootstrap data

In the early days of a product, the best framing on shortcuts is Paul Graham’s “Do things that don’t scale”.

Don’t view launch cheat codes just as “lean startup” pragmatism. Reducing feature scope to optimize for learning is an act of product humility. Even the best experiment driven teams only generate wins on <40% of launches, after-all.

“Is there a 2-way door?”

If the decision is, optimize for decision making speed; if it’s not, optimize for decision making quality. Borrowing from @JeffBezos:

The reality is the vast majority of decisions are two-way doors — as long as your org has the right post-launch sensors and is great at error recovery.
Error prevention is costly and time consuming. Use it only when absolutely necessary.

The ladder up move: figure out how to decompose a monolithic, seemingly 1-way door product decision into a sequence of reversible, stackable launches.

“Is this the right investment mix?”

Great product leads often take an investment approach and look at feature funding as portfolio allocation problem. It’s important to make sure teams are balancing the right mix of feature maturity bets.

• Seed = speculative bet with outsized upside. These could be entirely new product capabilities, swings at step-function changes in the growth funnel, features that can create new network effects, etc.
• Series A = validated customer demand ready to scale. These are often experiments or limited releases that looked promising; now it’s time to scale up to 100% and see what the full impact can be.
• Series B = proven, scaled feature needing 1.x features. The customer-feature fit is fully validated and a meaningful driver of the business. Now it’s time to relentlessly refine and improve the quality of the experience.
• … Series G = big company working on v10 of a plateaued growth product line that still has meaningful revenue. This is unlikely a place to do great product work.

A related great read on product investment types is Adam Nash’s post on 3 feature buckets: metric movers, customer requests, and and customer delight:

“What are the anti-goals?”

The goals are often boringly obvious; what you deliberately chose to not prioritize is more interesting and can force harder debates.

Good anti-goals range from metrics to use cases to customer types that you want to intentionally avoid prioritizing/moving.

An example: when improving Twitter’s timeline ranking, obvious goals might be tweet engagement rates and WAUs. A non-obvious anti-goal might be sessions/DAUs, which very well could decrease.

Questions > Answers

Recap of helpful questions to ask when reviewing product proposals:

• What is the fastest path to learning?
• Are there any cheat codes?
• Is there a 2-way door?
• Is this the right investment mix?
• What are the anti-goals?

Bonus: it’s easier to scale yourself with questions, and more fun for teams when they create the answers.

More where this came from

This story is published in Noteworthy, where thousands come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.

Want to work at Slack — in NYC? We are hiring talented engineers, product managers, and designers. Visit slack.com/jobs to find out more, or email me directly at nweiss @ slack-corp . com.

“In 2016, what’s an area you want Slack to make a big, new investment in?”

That’s the question Stewart Butterfield and I talked a lot about. We went through a slew of ideas: mining message histories to help alert people of relevant and timely messages, using the work graph to help people connect with internal experts, making the existing search significantly better for companies with rich message and file histories, building conversational knowledge bots, and more.

Slack is well on its way to building the new business operating system. Weaving in an intelligent layer is a huge opportunity to enhance the product for people who use Slack and the platform for developers who build on top of it.

That’s why I’m joining Slack to head up the new Search, Learning, and Intelligence group and start up its NYC office. The focus is on building features that make Slack better the bigger a company is and the more it uses Slack.

Our goal is to make people feel less overwhelmed by Slack’s information avalanche and give them superpowers to find fast answers — whether from their coworkers, search, or bots. The work will span many disciplines: search/information retrieval, recommendation systems, natural language processing, and machine learning. The success of the group will be measured in how much more productive, informed, and collaborative Slack users get — whether a company has 10, 100, or 10,000 people.

The Slack phenomenon is no secret

Based on the press, you would assume Slack had already replaced email for the entire Fortune 500 and had thousands of employees. The NY Times wrote “Slack is the Messaging App that May Finally Sink Email”, Inc called it the company of the year, Medium Backchannel announced “Shut down your office, you now work in Slack”, WSJ called Stewart the “2015 Technology Innovator” , and Slate wrote “Slack Off: How Workplace Chat is Changing Office Culture”.

Slack is “The fastest-growing enterprise software product in history” — Ben Horowitz

All of this is a testament to how transformative the existing Slack experience can be for companies that switch off email. Yet the Slack story is still just at the beginning. It has fewer than 350 people, under 1m paid accounts, and under 2 years since its launch. There’s so much more to do.

The NYC (Hiring) Plan

From its origins as Tiny Speck working on an MMORPG, Slack was a distributed team split between Vancouver and SF. This past year, Slack crossed the Atlantic to open up its Dublin office and will be soon be up and running in Melbourne. As Slack moves into ever bigger companies, it will need to work for increasingly distributed offices. Slack expanding its own geographic footprint is an opportunity to eat its own enterprise dogfood.

NYC is a great place to build technology products for many reasons:

• It has wealth of incredible technical talent from universities like Carnegie Mellon, MIT, Columbia, Princeton, Harvard, Cornell, Yale, NYU, etc., larger tech firms like Google, and finance companies with thousands of engineers.
• Combined with its growing but still relatively nascent startup ecosystem, NYC is a great place to hire. Companies like Facebook, Uber, Twitter, and Square have opened major offices in the past few years.
• It has a bigger diversity of people and industries than any other city in America, which fosters different perspectives than the Bay Area.

If you or someone you trust is an amazing engineer with a background in information retrieval, NLP, AI, or just moving fast to build scalable new products, please see this job posting or send an email to nweiss @ slack-corp . com !

A historical digression on collaborative tools

The roots of my interest in Slack are over a decade old. I’ve always loved the idea that collaboration tools could dramatically boost the happiness and productivity of teams. During winter 2005 for CS247, I helped build a document commenting and review tool called Collaboread. Just a few months later in March ’06 Google acquired Writely. The acquisition evolved into Google Docs, where I interned in ’07 as a UX designer working on review and revision history.

Over the next 7.5 years, I took a detour to work on search and recommendation systems. At Google, I was the PM lead for the structured search team, which evolved into the “Knowledge Graph”. At Foursquare, as head of product management I shepherded the personalized, proactive place recommendations service from SXSW ’11 beta launch to tens of millions of users today. All these projects took unstructured inputs, had machines learn a semi-structured understanding of the data, and then gave value back to users — exactly the kind of work this new Slack group will focus on by mining the message corpus.

Ch-ch-ch-ch-changes

As Fred Wilson wrote last week:

“Just this week I’ve been on the receiving end of a half dozen emails… that start with the news that a valued colleague has made the decision to move on… It’s that time of year.”

I sent my version of that email last week. After 5 years at Foursquare, it was time for an entirely new challenge.

Building productivity tools for enterprises couldn’t be more different than a social recommendation service for discovering great new bites and bars. But even though I’m switching companies, my love of the Foursquare team and product won’t end. Fred continues:

“A hallmark of great companies is the idea that departing employees who leave on great terms are roving ambassadors for your organization.”

I will still be a huge supporter, fan, and friend of Dennis Crowley and the company. I’ve written 547 tips, contributed 931 ratings, and saved 1,516 places. And over my week-long staycation between jobs, I made sure to go out as the #1 fan of the product:

Or: Why nice people don’t finish last

When Alphabet emerged in August, 2015, Larry made Sundar Pichai the CEO of the core business. Most people outside Google, Forbes included, all had the same question: “Who is Google’s New Chief?” Google’s notoriously focused on intellect, from the brainteaser interview questions to its sci-fi style moonshots. Yet the answer had very little to do with Sundar’s superior intelligence (despite his Stanford masters and Wharton MBA).

Everyone wants to be the smartest person in the room. That is an understandable goal early in your career. But to grow into an actual leader, intelligence is necessary but not sufficient. Constantly and combatively trying to establish your intellectual dominance is a losing strategy. Sundar’s rise to Google’s CEO shows a better path, where bringing the best out of others matters more than parading your intellect.

Sundar: The Great Compromiser

The press’ depiction of Sundar, long before he was CEO, has consistently been someone who brought warring factions within the Google behemoth together. He’s willing to defer judgement, give up teams, and lose arguments for the greater good. He deescalates the intellectual arms race that normally takes over in a culture like Google.

A profile in The Information from June ’14 (emphases are mine):

“What’s perhaps most striking about Mr. Pichai’s ascent at Google is that he has operated differently from most other senior executives at the company. Google has had a combative internal culture in its upper ranks and turf wars can be fierce, yet Mr. Pichai is subdued and usually eager to collaborate rather than wage a political fight. He’s even been willing to give up some territory for the sake of harmony with other executives — something that’s won him respect across the company and the trust of Mr. Page…

That “team player” approach has enabled Mr. Pichai to outlast or gain more power than his peers as Mr. Page has sought to quell infighting among top executives.”

The Verge interview from May ’15:

“Executives in Pichai’s position tend to lead their teams with vision, charisma, bombast, or (usually) some combination of all three. But there’s no bombast to Pichai. Pichai is thoughtful and friendly in person, nodding carefully as he listens and then responding with real empathy.”

The Guardian profile from Aug ’15:

“Pichai projects the image of a passionate nerd, but without any of the sociopathic egotism that plagues Silicon Valley executives (and their underlings). It’s a skill set that has made him one of tech’s most eligible executives.”

While I never worked with Sundar directly at Google, many close friends and former coworkers who have all have shared similar perspectives.

11 ways to grow your influence beyond your intellect

Instead of trying to to get people to respect your superior smarts, get them to want to follow your leadership. Whether you’re a product manager, an engineering lead, a manager, or a senior executive, there are a number of specific things you can do:

1. Develop personal relationships outside tactical work discussions. Go for a walk outside. Get a coffee. Drink beers or cold-pressed juices together.
2. Be more approachable, even if you initially think an idea is awful. Every idea is worth 5 minutes. You never know when one will be truly great.
3. Respond with more “Yes, and…” instead of “No, because…”. You’ll get better ideas encouraging others instead of shutting them down.
4. Show more emotion, ditch the poker face, and expose chinks in your armor. People want to work with other people, not emotionless robots.
5. Never let your frustration show in a meeting, and even more importantly in email/slack.
6. Can you make a great argument for the other person’s side? If you can’t, put on your empathy hat. You might convince yourself to compromise.
7. Force hard decisions, but make few decisions unilaterally. Make sure to communicate them tactfully with everyone involved.
8. Make fewer assertions. Ask more pointed — but not aggressive — questions.
9. Make fewer demands. Your ratio of suggestions : informed observations : directives should be 100:10:1.
10. Give credit 10x more than you take it, and take blame 10x more than you give it.
11. Be relentlessly optimistic and perpetually pragmatic. Hope is inspiring, as long as it’s grounded in reality.

Get people to love working with you instead of hating how smart you are. If it worked for Sundar in Google’s hyper-intellectual culture, it probably will work at your company, too.

There are many great definitions of product management. There’s universal agreement that the best PMs are utility players who have a range of skills that lets them jump into almost any role so they can do whatever it takes to ship products faster. Between diving into details and reacting to incoming requests — from engineering, design, sales, marketing, support, PR, legal, and more—it’s easy to get sucked into spending 100% of your time with a time-horizon of the release date two-weeks out.

It’s a trap.

Google’s investment approach

Take a lesson from Google. Back in 2005, just post IPO and with their core search and AdWords businesses growing at a tremendous pace, Google realized that all their resources could easily get sucked into the vortex of refining their core products. They could get lulled into the monotony of continuous iteration. So Schmidt, Page, and Brin forced Google to invest outside the core.

We spend 70 percent of our time on core search and ads. We spend 20 percent on adjacent businesses: Google News, Google Earth, and Google Local. And then 10 percent of our time should be on things that are truly new.
- Eric Schmidt, 2005

While this is somewhat related to Google’s notorious “20% time” for engineers, Schmidt’s point was broader. Google wanted to invest 20% of its resources on new businesses built off the strong foundation of search/ads, and 10% of its time on completely new ideas that could seem crazy.

Schmidt was forcing Google to think about where to deploy its resources like investors think about allocating assets. The mix of investments depends on risk profile and time horizon. With its monopoly-like profits and founder-friendly share class structure, Schmidt knew Google had an abundance of capital and time. He wanted to make sure Google took advantage by investing in high risk, high expected return projects to optimize for its long-term success.

A Product Manager’s 70/20/10

While Google likely has a longer time horizon than your company, its allocation approach makes sense if you just compress the timespan.

I think the ideal mix of a PM’s time is 70% on the coming weeks, 20% on up to a quarter out, and 10% further out than that. This maps neatly to my post on roadmaps: 70/20/10 on #now/#next/#later.

Avoid the trap of spending 95% of your time on reactive tasks. You will never leave room to come up with, nurture, and develop the big new ideas that change the trajectory of your product.

Steady vs. Spurts

Many PMs shift their time allocations around lumpily. It’s easy to go all the way to 20/80/0 for one week of the quarter when you are putting together a roadmap. Everyone loves a week dedicated to brainstorming.

Consistency works better here, however. It allows more time for ideas to marinate and to bounce them off other people. It allows time to prototype and figure out engineering costs before having to commit to building a feature.

And it will produce better ideas, because it gives you time to observe. It is easier to come up with one new idea every week than 10 ideas in a one-week sprint.

Paul Graham’s great essay on How to Get Startup Ideas explains this well:

Since what you need to do here is loosen up your own mind, it may be best not to make too much of a direct frontal attack on the problem — i.e. to sit down and try to think of ideas. The best plan may be just to keep a background process running, looking for things that seem to be missing. Work on hard problems, driven mainly by curiosity, but have a second self watching over your shoulder, taking note of gaps and anomalies.
- Paul Graham, 2012

There’s a silver lining to the 70%: your everyday job as a PM should be filled with clues for new ideas if you start looking for them. The results of that Hive query you ran, the surprising A/B experiment result you analyzed, the user research session you sat in on, the sales meeting you presented at, the competitor product you tried, the whiteboard session you designed in—all these short-term tasks are filled with seeds for future feature ideas. Open your eyes and write them down.

How about other roles?

I cannot say for sure, but I suspect many other roles could benefit from taking a similarly structured approach. For example:

• Designers: 70% on the visual specs for upcoming features, 20% exploring new features, and 10% on wireframes for entirely new concepts/styles.
• Engineers: 70% building features and fixing bugs, 20% on prototyping fledgling ideas or exploratory data analysis, and 10% on speculative initiatives like a 10x performance improvement.
• Sales: 70% on closing deals, 20% on bigger I/Os for the next quarter, and 10% on long-term relationships with agencies and big advertisers.

Maybe those percentages are not quite right or the tasks are a bit off, but it does seem like a potentially useful approach.

While you probably don’t have the luxury of building a self-driving car for 10+ years out, you also cannot afford to only focus on two weeks out.

You are completely responsible for shipping products fast, above a minimum quality bar, and with the right scope. But your job doesn’t end there. Clean up your calendar, shut off your email occasionally, keep track of insightful observations, and set aside time to think further ahead.

You need to live in the future and bring great ideas back.

Want to read more related posts? Check out:

• #now, #next, #later: Roadmaps without the Drudgery. A deceptively simple process for prioritizing projects that won’t cause a revolt.
• 54 Articles and Books that will Make you a Great Product Manager. From Horowitz to Christensen to Graham to Spolsky and more, a collection of the best articles and books from the best product leaders.
• The Lego Block Exercise. What Drove Foursquare to split into 2 apps.

Want to work at Slack — in NYC? We are hiring talented engineers, product managers, and designers. Visit slack.com/jobs to find out more, or email me directly at nweiss @ slack-corp . com.

Manage Your Time Like Google Invests its Resources: 70/20/10 was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

Wartime PM

The product manager corollary to @bhorowitz’s Peacetime CEO/Wartime CEO

Ben Horowitz’s definition of war and peace in business is perfect:

Peacetime in business means those times when a company has a large advantage vs. the competition in its core market, and its market is growing.

In wartime, a company is fending off an imminent existential threat. Such a threat can come from a wide range of sources including competition, dramatic macro economic change, market change, supply chain change, and so forth.

This piece is about what great product managers do when they’re at peace versus at war. Spoiler: most PMs, especially PMs at anything resembling a startup, are at war almost constantly.

Even when I was a PM at Google working on search in 2010–2011, we were at war against Bing. Its “decision engine” put answers to queries above links, which was an existential threat to Google’s dogma about what search results could be — until the Knowledge Graph, the product I helped start, finally launched.

The differences

Peacetime PM writes vision docs about where the industry is heading and dream use cases for 5 years out. Wartime PM focuses on near-term execution since their company might not be here in 6 months.

Peacetime PM thinks other competitive products are complements that will grow their market. Wartime PM suspects every product is a substitute that will steal her users.

Peacetime PM reads TechCrunch all day looking for companies to buy. Wartime PM skims Techmeme every other day to watch their back.

Peacetime PM avoids conflict and lets ideas percolate throughout the organization over months. Wartime PM embraces disagreement and pulls everyone into a conference room to make a decision that afternoon.

Peacetime PM hates to ever take top-down direction. Wartime PM relishes clarity of focus, even if it comes from someone else’s idea.

Peacetime PM runs a 41-way multi-variate test to find the perfect shade of blue for links. Wartime PM trusts her designer and knows there are bigger hills to climb.

Peacetime PM creates dashboards and runs experiments to improve feature-level vanity metrics. Wartime PM optimizes for top-level active users.

Peacetime PM wants development to work like a waterfall: write a spec, get designs, build it, test it. Wartime PM tries to parallelize everything.

Peacetime PM writes 25-page comprehensive specs. Wartime PM writes 3-page specs that addresses non-obvious issues and contentious questions.

Peacetime PM encourages teammates to take a month to explore far-fetched ideas. Wartime PM keeps her team focused on speed to shipping.

Peacetime PM trades time to launch for expanded scope. Wartime PM can’t afford the time or extra complexity from scope creep.

Peacetime PM thinks it’s always worth adding extra polish to a release. Wartime PM understands what the minimum acceptable quality bar is.

Peacetime PM asks UX research to do a 3 month, 25 person diary study. Wartime PM asks UX research for relevant findings from past studies and for an 8-person, hour-long cognitive walkthrough to validate an idea.

Peacetime PM builds complex Excel models. Wartime PM uses napkins.

Peacetime PM thinks building a feature 5% of people will use is worth doing. Wartime PM focuses on only the features 80% of people will use.

Peacetime PM likes a comfortable pace. Wartime PM knows that’s a temporary luxury.

Am I at peace or at war?

Can you ignore your dashboards because key metrics always go up? Do you get 5 more engineers on your team just by asking? Do you never get involved in closing a candidate? Does your team build custom animation frameworks for new products before validating there’s user demand? Does a +0.1% result from an experiment get your boss excited? Do you have the Stocks app on your homescreen so you can track your net worth from your public company RSUs every day?

If so, then congratulations you are one of the lucky few PMs working in a peacetime environment! Otherwise:

Welcome to war.

Want to work at Slack — in NYC? We are hiring talented engineers, product managers, and designers. Visit slack.com/jobs to find out more, or email me directly at nweiss @ slack-corp . com.

By Noah Weiss, VP Product at Foursquare

A year ago, with Thanksgiving fast approaching, we started thinking about what were the big areas Foursquare could invest in for 2014. It seemed obvious: make checking in faster, improve search quality, make the venue page more authoritative, and so on. It was a reasonable plan. It was an uninspired plan.

So we started over. We listed out all our assumptions about the constraints we had:

1. A hybrid privacy model: Foursquare supported symmetric friendships, because check-ins are sensitive location data. It also had a public follow model, since tips are about broadcasting your expertise.
2. Two overlapping content types: check-ins are ephemeral, tips are evergreen, yet they both tie text and photos to a place.
3. A location sharing brand: that seemed inextricably tied to our search product, even though many people who said they wanted personalized recommendations had no interest in sharing their location with friends.
4. Personalization fueled by check-ins: that’s the flywheel that improves the experience the more you use the product, yet our ability to passively snap people to places was getting significantly better every day.
5. A single app: it seemed like there was no way to break this one.

Then we threw all the constraints away, laid out the great assets we had to work with, and imagined from scratch what world we would build if we started anew.

This post is about how we set up the Lego Block Exercise, and why you should do it for your company, too.

Clear off the table

Start off laying out what beliefs your company holds most precious. The dogma that boxes in most discussions, as if those beliefs were rules of nature. Here are some examples prominent tech companies face today:

• Twitter: the feed is fueled by people you explicitly follow.
• Uber: we transport people from point A to point B.
• AirBnB: the guest experience is controlled by our hosts; we’re just a marketplace.
• Pinterest: our product is for discovery; our publishers handle commerce.

These are the firm lines companies draw that help them focus. They are the bumper lanes management gives teams so they don’t throw the ball into the gutter.

These firm beliefs let you operate without constant existential angst. But for this exercise, enumerate them and make sure everyone knows none are sacred. A great new direction doesn’t require you throwing them all away, but you have to be willing to.

Lay out the blocks

Why do people love your company? If you break down the product, what are the critical pieces? What is the foundation the whole experience stands on? What can your company do no one else can?

These are your lego blocks. 3 is too few, and 30 is definitely too many. When we did this exercise at Foursquare, these were some of the blocks:

• 6 billion+ check-ins: the unique data asset that fuels everything.
• 50m+ tips: the perfect length content on mobile to answer the question, “What’s great here?”
• Pilgrim: our background location technology, built off 6 billion+ check-ins, that can snap people to places and send magical push notifications.
• Explore: our personalized local search engine that blends in your interests and the places people you trust love.
• Venue database: the biggest and highest quality unencumbered database of places that has strong coverage in nearly every country on earth.

There were about a dozen more. The best way to phrase the question to find all the lego blocks was, “If you left your existing company and could take anything you wanted with you, what would give you the biggest unfair advantage versus another startup?”

Assigning homework

We did this exercise when we had around 150 people. It felt like 10 was the right number of people to invite. Any bigger and the discussions would have gotten unwieldy. We pulled together a set of people spanning product, design, server and client engineering. We encouraged them to pull in the best ideas from the rest of the company. This all happened in the open, with regular updates at company meetings, and letting anyone submit homework if they had ideas they were passionate about. The blend of support from the CEO and the bottom-up generation of ideas is a big part of what made this exercise work.

At the kick-off meeting, we gave out these exact rules:

You can use some of the lego blocks, or you can use all of them. You can invent new ones. You can dream up changes to the existing app or dream up three different apps. You can pitch “1 app and a website” or “three apps and two websites”. Feel free to seek inspiration outside of this room — there are so many smart people with great ideas here at Foursquare and I strongly encourage you to think of yourself as a “gather of great ideas” over the next 10 days.

We quickly realized it would be helpful to provide guidelines for what a great proposal would look like. It made sure every team addressed the hardest questions we needed to answer before picking a direction.

The pitch: what’s the 1-line tagline for your service? How would a friend tell another friend to download it at a bar? If someone asked, “How is this different from…”, what would you say? What people are you building for and what problems of theirs are you solving?

The product experience: what you would actually build, what are the key features, how do they connect. Anything from sketches to wireframes to visual designs to prototypes can be useful here.

The rationale: why are you confident this strategy will work? Piece together user research, our own data, external data, competitors, and a coherent argument.

The plan: if we started working on this the week after Thanksgiving, what order loosely would we build things? How could we quickly validate assumptions and test hypotheses? How would you roll it out? A user acquisition plan matters.

You could reuse this exact assignment, since it intentionally had very little specific to Foursquare.

A surprising consensus

We wanted the ten people to go off in divergent directions. Except for one checkpoint where people could merge into teams, we wanted them to not talk to each other.

It turned into one of the company’s most productive two weeks ever. People quit their day jobs, effectively. They stopped responding to emails, Asanas, and meeting invites. Everyone just started writing, and wireframing, and editing all the crap ideas out every day. Throwing out the constraints, people realized how much had held their thinking back.

I joined up with one of our engineering leads who was part of the 10, since we were 90% moving in the same direction. Two great designers joined us.

Before our roundup meeting, everyone sent out their proposals for people to digest overnight. The next day, everyone came in with the same shock: we all basically agreed. There were huge differences in people’s approaches, which it took months to hash out and take the best pieces of, but at a high-level almost everyone came to the same conclusion.

Maybe we were lucky. I have a feeling, though, that beneath most companies’ strategic plans is a set of better, bolder ideas that people would almost universally rally behind. It just takes relaxing the previously firm constraints and laying out the company’s lego blocks to get there.

For the future

The biggest benefit of the Lego Block exercise was it broke us out of the lull from the monotony of continuous progress. We had fallen into a rhythm of bi-weekly product reviews: metric X +1.2%, metric Y -0.4%, launched experiments A and B, starting design for a new feature improvement, etc. It made us feel like the machine was humming. Metrics moved! Experiments (in)validated assumptions! But to what end?

The Lego Block exercises forces your company to do painful, important thinking.

Some lessons we learned for the next time we do this:

• Get a wide range of views: pick a mix of engineers, designers, PMs, and other roles depending on your company to see how people from different disciplines would approach the challenge.
• Hunter-gatherer: each person is hunting for great ideas. Heavily encouraging them to gather them from across the company. It will surface more great fodder, and everyone will feel more invested.
• Don’t sweat the details: when people reconvene, focus on the commonalities. What assumptions did everyone agree the company has to throw away? What key experiences were broken? What lego blocks were missing? Ignore all the small details, which teams will figure out once you start building.
• Not the sum of parts: be careful of turning all the proposals into a Frankenstein. Take the best ideas, but merge them into something that is cohesive and stands on its own. This isn’t roadmap by commitee.
• Start teams with problems: even though many of the proposals will have detailed solutions, you should give your newly staffed teams clear problems to solve and lots of leeway on coming up with answers. Resist the urge to make an uber-plan that strips away teams’ creativity.

That’s it. Get started.

Want to work at Slack — in NYC? We are hiring talented engineers, product managers, and designers. Visit slack.com/jobs to find out more, or email me directly at nweiss @ slack-corp . com.

The Lego Block Exercise was originally published in Foursquare on Medium, where people are continuing the conversation by highlighting and responding to this story.