Archive of posts with tag 'Planning'

Forget estimates, start with appetite →

June 13, 2025 • #

In the latest issue of Building Blocks, I dove into Shape Up and its idea of setting the appetite for a project.

Fundamentally, appetite inverts the question we begin with when planning a project.

Instead of starting with “Here’s a spec. How long will it take?”, we start with a time window we’re comfortable spending on the problem and ask “What can we get done inside this box?”

Rather than define a richly-detailed design of what we want, appetite requires us to start with a problem definition, and refine that first. If we narrow the problem down, we also narrow the solution space. Solutions are allowed to be smaller and more focused.

The appetite starts with time boundary and works backward to a design that fits inside.

Appetites define sound and acceptable constraints up front. And constraints are wonderful tools for generating creativity.

✦

How I Plan My Week with Roam

November 4, 2020 • #

For years Todoist was my tool of choice for task management. When Roam came on the scene for me earlier this year, I’d seen pretty compelling methods from the #roamcult for how to manage todos inside of Roam with its TODO feature. It was an intriguing idea: such a fast and simple way to capture things without leaving the current frame.

But it took me a while to go all-in on Roam for tasks. Todoist was so embedded in my muscle memory, especially with its accessible web and cross-platform mobile apps and its excellent quick-entry “Quick Add” flow from the desktop. It was going to require a lot to make the switch to a different system, and one that’s wildly different from the way any other task management app works.

I eventually took the plunge, moved all my pending tasks over to a Roam page from Todoist, and started to come up with a process. I was first just managing tasks from a giant temporary “Inbox” page, but over time I learned better how I wanted to fit them in with the advantages of a Roam-based daily workflow.

Though the switch to Roam for task management gives up some useful abilities with dedicated favorites like Todoist or Things, the gains with managing tasks alongside the rest of my knowledge graph are well worth the trade-offs. Most task management tools have way too many features for my needs, anyway. Here are just a few things I love about this process so far:

You can insert todos in context — Being able to quickly slot todos anywhere is beautiful. As you’re writing other notes specific to projects, meetings, phone calls, articles, or anything else, you can Cmd-Enter and add something right as you’re thinking of it. This method ends up being a solid “ubiquitous capture” flow similar to what you’d do with Todoist or OmniFocus inboxes.
The [[TODO]] page, pinned to the sidebar — This lets you quickly dredge up all of your todos regardless of where you scattered them. Use this plus filters to drill in to specific areas. A solid “inbox” equivalent to process your todos into other places.
Add tags to filter for context — If you’re familiar with [GTD’s contexts](https://evomend.net/en/what-not-gtd-context/ “Contexts in), you’ll recognize this. I add tags to tasks so I can filter for all [[TODO]] tagged #Email, for example. Now let’s go over how I plan out my week with Roam.

My Weekly Process

At the beginning of each week, I start out by creating a new page for the week ahead, dated starting on Mondays. So this week’s page is [[📆 Weekly Plan: 2020/11/02]]. I just focus into the search bar and type it out.

For the page template I start out with sections for Weekly Goals and Daily Goals. The first I treat like a general holding area for tasks I want to work on in the upcoming week, and the latter I include a block for each day. Then I manually add in the dates for each day with Roam’s /date picker slash command (/today and /tomorrow can also be useful here, if relevant)¹. To make all of this faster, I use a TextExpander snippet to automatically insert the basics. Typing rcwp stamps in my basic template²:

- # Weekly Goals
    - 
- # Daily Goals
    - Monday: 
    - Tuesday:
    - Wednesday: 
    - Thursday: 
    - Friday:

When I started down this workflow path, I initially thought it’d be annoying to have to set up a new page each week. But so far it’s actually been valuable to force a start-of-week planning session to think through what I want to get done. Usually on Sunday nights I’ll go in and make the Weekly Plan page, then pull up my [[Projects]] page, [[Blog Ideas]], [[TODO]], or even my page from the previous week to look for all of the various tasks I might want to focus on.

Using the sidebar helps a lot here. I’ll pop open other pages with a Shift-click, then drag over todos I want to work on under the Weekly Goals section. If I want the todo to actually stay where it is and not move it to the Weekly Plan page, I use Roam’s Alt-click and drag to bring over a block reference instead of the entire block itself. This is a neat way to keep todos in the right place, but have a reference to them in your task plan. There’s an example of this in the video below, where I’ve got a trip planning project page with tasks on it that I want to stay there, but still see in my weekly view.

Once I’ve got a batch of tasks entered under the week, I’ll start queueing them up into their appropriate days. Some things have deadlines or due dates I’m trying to manage to, so need to get done at specific times. Others I’ll just leave in the Weekly section until I know when I plan to do it. Regularly on weekday mornings I’ll go to my plan and pull in what I want to get done that day. It’s a living document until the week is over, a part of my morning routine to go to this page.

My favorite thing about this process is how it manifests your tasks on the Daily Notes page. Because the Daily Note automatically displays references to any page that includes that day’s date, you get a slick little embedded list of the day’s tasks. The Daily Notes view is my default working mode during a typical work day, so this is an excellent place to have all of those queued up activities available on the same page where I’m taking meeting notes and the like.

Areas for Improvement

After about 2 months committed to this process, it’s pretty solid for me. I’m not missing as much from my old workflow as I thought I would, and I’m enjoying the benefits of Roam’s graph structure too much to reconsider now. Plus the potential is high that the lightning-fast Roam team will add improvements to all this.

Todoist’s Quick Add is something I’d love an equivalent for somehow in Roam. The Capture mobile entry web app that Roam has isn’t bad, but it’s not that fast for adding new items quickly while on the go. To fill in this gap now I’ll usually just throw things into a sheet in Drafts which gets processed later back at my desk.

Multiplayer abilities were something I never took advantage of in Todoist, but are a key piece of any work (or even family) project management usage. Roam’s recent additions in support of multiplayer look promising here, but that hasn’t been relevant to me just yet. Multiuser project management (that tools like Asana excel at) is a beast in itself to solve.

Managing dates isn’t as smooth as in most task management apps, but there are some advantages I really do like. For any task entered anywhere in your graph, you can add a future date to it and have it magically appear in Daily Notes references that day to jog your memory. A feature that no task management tool other than OmniFocus ever supported, but I’ve wanted ever since, is the idea of a Start Date. With that you could put in something you want to remember, but for later, put “in 90 days” next to it and it would disappear until resurfacing then. It was a great way to put in things you know you needed to remember, but don’t need to continue seeing in your list for weeks until it’s relevant. Dating your todos like the above is similar in concept: tagging them with a date 3 months out will make them pop back up when they need to be considered.

The Future

From what I’ve seen in Twitter discussions about the incoming Roam API, I’m hopeful that its hyperactive developer community will jump right into building applications on Roam for workflows like this. A dedicated, customizable app specifically for task management built on the “Roam platform” would be a phenomenal tool worthy of driving its own second-order revenue for a developer. Thinking about David Crandall’s piece on the prospects of Roam as a service layer, there’s so much potential for it to power its own developer marketplace.

In the next post I’ll go over my current workflow for using Daily Notes. It’s an interesting companion to this process of task management.

If I was fancier I could probably add this logic to my TextExpander snippet, but adding dates manually doesn’t bother me. ↩
This setup will look familiar if you’ve seen Nat Eliason’s Effortless Output course. I also found this Alfred workflow with a similar template. ↩

✦

The Idea-to-Reality Production Stack →

August 16, 2020 • #

A great overview of mental models, thinking approaches, and techniques to, as the piece says, go from “idea to reality.”

✦

Don’t Let the Backlog Drive Your Product →

November 7, 2019 • #

As we’ve started to adopt a process similar to Basecamp’s, we’ve been revisiting how we think about “backlogs” — the list of ideas and various requests we could work on in the product roadmap.

I liked this piece from Rich Ziade on the downsides of backlogs.

The term “backlog” makes me anxious. It implies being behind. It also implies that what you’ve got today is an incomplete thing. You need to get through that backlog. It also implies–dangerously–that this is the true unrealized ideal for a product.

After working on a (now) successful product for almost 10 years, this one is familiar:

When any piece of software makes it out into the world, inevitably feedback follows. The bigger the impact of the software, the louder and more varied the feedback. It’s actually a sign of success.

✦

Weekend Reading: Attention, Hill Climbing, and Enforcing Culture

October 5, 2019 • #

🧠 To Pay Attention, the Brain Uses Filters, Not a Spotlight

For a long time, because attention seemed so intricately tied up with consciousness and other complex functions, scientists assumed that it was first and foremost a cortical phenomenon. A major departure from that line of thinking came in 1984, when Francis Crick, known for his work on the structure of DNA, proposed that the attentional searchlight was controlled by a region deep in the brain called the thalamus, parts of which receive input from sensory domains and feed information to the cortex. He developed a theory in which the sensory thalamus acted not just as a relay station, but also as a gatekeeper — not just a bridge, but a sieve — staunching some of the flow of data to establish a certain level of focus.

⛰ Climbing the Wrong Hill

Using the hill climbing problem as an analogy for challenging yourself and achieving long-term goals.

👨🏽‍💼 What Do Executives Do, Anyway?

The key takeaway of High Output Management:

To paraphrase the book, the job of an executive is: to define and enforce culture and values for their whole organization, and to ratify good decisions.

That’s all.

Not to decide. Not to break ties. Not to set strategy. Not to be the expert on every, or any topic. Just to sit in the room while the right people make good decisions in alignment with their values. And if they do, to endorse it. And if they don’t, to send them back to try again.

✦

Right-sizing and Product Scoping

October 31, 2018 • #

In product teams you’re continually faced with the challenge of scoping. When you build something directly for a customer, for a fee (consulting), the scoping process is explicit and has built-in constraints — customer expectations, funding, timelines, deliverables. Even in that scenario, agreeing on a firm scope for an effort isn’t simple, but it’s even harder when working in a product company. The same constraints still exist, but in a more nebulous, undefined form. Constraints aren’t imposed and enforced externally by a single client dangling the paycheck. The demands are dispersed amongst thousands of users with sometimes-competing desires, paying varying amounts for your product. So it’s on you to define hard edges based on your own goals and objectives.

When you set down the idea for a feature’s implementation, you always want your new feature to be cooler or more powerful than you’re able to commit to. With even a touch of investigation, you discover that it’ll take many cycles to get to get all the way there. So you have to forgo achieving your complete vision and put up some boundaries at an interim milestone along the path. This is one of the hardest parts of product design — you have to knowingly ship something “incomplete” according to your vision, but that’s directionally aligned and a solid waypoint on the journey.

If you’re setting your own objectives, you have no one telling you exactly what to ship, how much to spend, and when to be done. Not to downplay the complexities involved in consulting, but the incentives and constraints are generally much clearer; you’re unlikely to commit massive resources to a hazy and overzealous goal, and the customer isn’t likely to pay you what it’d take to commit — so you compromise.

When it’s your own product, you still have end customers, but their individual wishes and needs are distributed enough that it’s on you to synthesize what customers want into a clear vision you can break down into parts, and to enforce your own boundaries. No one is forcing any particular constraint; you could spend months crafting and polishing the most perfect version of the feature until the final day you get it out there. But good products come about as a consequence of savvy incorporation of market feedback into the development process. The best model uses increments that are each valuable enough to earn committed investment and experimentation from customers, which gives you the feedback you need to validate what you’ve made and make the right course-corrections along the path to the vision. As clear as your vision might be, it’s still not proven until it intersects with reality. Like the old adage says: “No plan survives first contact with the enemy”. Or the customer, as it were. Real-world feedback is what separates a vision from a hallucination.

Yoy need to create a trail toward your vision with release points along the way that each constitute something “complete” enough to use and validate. And that’s where I think the core problem lives in product development: the balance of between shipping enough to consider a feature useful but soon enough that you can start measuring the impacts that will inform your next waypoint. Once you’ve established your vision for what you want to achieve, you then carve away at it until you have essential stages that work as milestones. In the best cases, each milestone can be a defensible stopping point for a feature. You could ship v1, never revisit the idea, and still have something whole and useful. The scoping process is a painful, but critical step to getting a useful enough product feature soon enough to close the feedback loop and begin iterating. I find the Shape Up idea of “appetites” a useful metaphor for selecting milestones:

Whether we’re chomping at the bit or reluctant to dive in, it helps to explicitly define how much of our time and attention the subject deserves. Is this something worth a quick fix if we can manage? Is it a big idea worth an entire cycle? Would we redesign what we already have to accommodate it? Will we only consider it if we can implement it as a minor tweak?

It’s tempting to make the scoping and appetite-setting process a group exercise, to fold in product management, design, engineering, ops, sometimes even marketing. A wider aperture of company buy-in makes sense at a macro vision level, but once you get down to the ground defining specifics, you need fewer people involved to be able to drill in on what’s most important. If possible, it’s best to involve only those directly responsible for defining and building the thing in question. Too many heads involved generates too much free-form “ideation” and not enough of the brass-tacks horse trading required to make hard tradeoffs necessary.

I have a two-part theory on scoping:

Projects scoped by large committees tend to get larger — the average contributor knows it’s unlikely the next idea tossed into the hat will fall in their lap to execute; lots of people just get to be the “idea person”; incentives to both signal “big thinking” and define concrete goals are competing with each other
Projects scoped by individuals or small groups tend to get smaller — because you’re on the hook to build everything, all of the skin in the game is yours; incentives are aligned on making things tangible and reachable

Landing somewhere in between is ideal for product scoping. Removing things from the vision (or deferring) requires honesty, commitment, and focus, which are all much easier to guarantee in small groups.

We’re often too idealistic with scoping and think we can “squeeze in that One More Thing”. Stretch goals are fine and can be motivating, but too far-fetched of an objective point can end up setting the wrong expectations across the company. If you’re not more aggressive with the hatchet than you think you need to be in the early stages of feature planning, the whole team (and your customer) will be worse off.

✦

Browse the full archive →

✦