Jordan Koschei jordan koschei

Product

The Problem with Hill Charts

At Dwell, we use Hill Charts, a project management tool developed by the folks at Basecamp and built into Basecamp 3.

A Hill Chart in action
This image comes from Basecamp's blog post announcing Hill Charts in Basecamp.

What are Hill Charts?

The basic premise is this:

To-do lists are imprecise (what does it mean for a project to be “42% done?”), so we need a visual representation of progress. A Hill Chart is a subjective visualization of progress in which each to-do is a dot positioned on a hill. The left side of the hill is for figuring out the unknowns of a project; the right side is for implementing the knowns.

The left/uphill side is for problem-solving, consideration, and figuring out uncertainty. The right side is for execution, implementation, and confidently taking care of the knowns.

Note: For more about Hill Charts beyond my oversimplified explanation, you can read Basecamp’s article, or watch this video from Ryan Singer (also embedded at the end of this post).

What’s Good About Hill Charts

I’ve found it helpful to have a visual representation of where we stand with different tasks, even (especially) if that representation is subjective. Hill Charts maintain a history, so you can scroll back and see the progress that’s been made in different places.

I haven’t done this, but I suspect that if I looked at the history of all of my tasks and projects, I’d see overconfidence at the beginning tapering off into realism as the dots get closer and closer to the end. Lots of progress in the “figuring things out” phase, followed by the realities of implementation bringing me back to earth.

What’s Bad About Hill Charts

Okay, now the part that was promised in the post title. There are some things I don’t like at all about Hill Charts, and while I don’t have a proposed solution, I thought I’d list them here in case somebody has some ideas:

Equal horizontal movement ≠ equal work. Moving a dot 50px on the left side of the chart doesn’t necessarily equal moving a dot 50px on the right side of the chart. It’s possible to go up the entire left side of the hill in a day, but take weeks to go down the right side. The time it takes to figure out the implementation of a task isn’t necessarily the same as the time it takes to actually implement it.

A downward slope implies ease. The “Figuring Things Out” side of the chart moves uphill, making it look like a slog. The “Making it Happen” side goes downhill, making it look easy. “It’s all downhill from here.”

The difficulty slope of each project is different. Sometimes, the figuring-out process is more difficult than the implementation; other times, the implementation is harder than the figuring-out process. There’s no way to express this on a Hill Chart, since the slope is identical for every project.

Progress gets more granular as time goes on. I’ve noticed this in my own usage of Hill Charts, so it could be just me. At the beginning of a task I tend to be overzealous in moving the dot from left to right. I’m pretty confident during the “figuring things out” process, but then once the implementation starts I move the dot smaller and smaller distances. The last portion of a task usually has a bunch of moves of a few pixels each. Maybe I’m just using Hill Charts wrong, or not breaking my work into tasks that are granular enough, but I suspect Hill Charts unintentionally incentivize this kind of usage.

Hill Charts are deliberately subjective, so perhaps this critique isn’t entirely fair. But since they’re specifically paired with to-do lists, I think they should be a more accurate reflection of the actual work it will take to move through a task.

How to Fix Hill Charts

We need a visual representation of progress through a task list. Hill Charts are a start, but I think we need a solution that incorporates some additional attributes:

Variable difficulty slopes. The user should be able to set the slope of the hill. Some projects might have a lengthy, shallow Figuring it Out segment; others might a steep, quick left side but a shallow, lengthy implementation side. Let the user decide.

Sketches of Hill Charts with variable slopes

Flexible difficulty slopes, with history. The initial slopes might be inaccurate, so users should be able to change it on-the-fly. These changes should be rolled into the Hill Chart history, so we could visualize how it’s changed over time.

A sketch of a Hill Chart with a slope history

I don’t know exactly what this solution would look like, but I’m hoping someone on the internet (or maybe Future Me) can help flesh this out into something real.

More About Hill Charts

Basecamp’s excellent Getting Real channel has two videos on Hill Charts as part of a larger series on how they work. Here’s the quick primer:

And here’s a more in-depth explanation with examples:

A Note About Ryan Singer, Product Genius

Hill Charts were pioneered by Ryan Singer, who leads Product Strategy at Basecamp. If you’re interested at all in product work, you should follow his writing and videos — I’ve learned more from reading him than almost any other single product person. His work gives me the same feeling as Ben Thompson’s or Patrick “patio11” McKenzie; it’s like they’re seeing in four dimensions what the rest of us only perceive in three.

Ryan Singer is @rjs on Twitter, and his website is feltpresence.com.

Productized Services

A podcast episode got me thinking about Productized Services — basically, taking a consulting service, standardizing the way you provide it, and selling it as a product.

Services are more flexible, but less scalable. If you’re a web designer who builds WordPress sites for clients, there are only so many projects you can take in a year, but those projects can be as custom as your clients need. You can charge more, because it’s your time and your expertise that are being sold, and those aren’t fungible.

Products are more scalable but less flexible. Instead of building custom WordPress sites, maybe you offer website setup and maintenance, with a starting fee to establish a website and perform minor tweaks on a WordPress theme, and a monthly maintenance cost. You charge less because there isn’t as much room for customization — you’re charging for the website itself, not your time and expertise creating it. However, you can sell more, because your process is systemized and can be performed more quickly, and you can train others to follow your procedures and help you.

As a service, the onus for setting the scope falls on the demand side. (“What do my clients/customers need?”)

As a product, the onus for setting the scope falls on the supply side. (“What do I offer my clients/customers?”)

It isn’t usually this cut-and-dried, and I sure hope you aren’t building WordPress sites for clients in 2019 unless your services are reallllly niche or special (we have SquareSpace now). But I think this is a good example for how productized services differ from regular services.

Building an Online Community

You are the framer of the Constitution in this world that you are building. You are the Abraham in the series of begats.

I’m a big fan of Reid Hoffman’s podcast, Masters of Scale. In the most recent episode, featuring Caterina Fake (of Flickr fame), they discuss how cultures form in online communities. Social networks become their own “civilizations,” and the founder is “the Abraham in the series of begats,” carving out the culture and mores which will define the community.

Masters of Scale title card

This idea has been on my mind a lot since I launched the Hudson Valley Talentbase. The early tone of the community sets the tone for the entire project — attract trolls early, and it becomes a platform for trolls. Shut them down, and they’ll congregate elsewhere.

Talentbase is still young, and there are only a handful of users that I’d consider “active,” but I’m already seeing the seeds of what the community could become. Some users are engaging with the platform in interesting and unintended ways — using the “Post Your Work” feature to post nascent ideas, for instance, or using it as a blogging function. The norms are already being set. I’m no longer the one controlling the experience — I’m just setting up the framework and watching how users interact within.

My fear of setting the wrong tone early was part of the reason I first launched it as an invite-only platform. I wanted the initial population to be made up of people I trusted, and the people they trusted, so that I could establish Talentbase as a place to showcase high-quality work and have high-quality conversation. Hearing two well-pedigreed social media founders discuss this exact idea is validating.

Some other ideas I found interesting from the episode:

  • Towards the beginning of Flickr, there was a large userbase in the United Arab Emirates, but also a large number of photos of Britney Spears with a bare midrif. Those turned out to be mutually exclusive populations — by allowing the midrif photos to continue, Flickr caused their UAE userbase to migrate elsewhere.
  • There’s no such thing as an objective platform. Every online community stands for something, based on the rules it chooses to enforce, but only some communities know what they stand for.
  • Every founder of a social network understands what lines can’t be crossed. Only some of them vocalize those boundaries and codify them for the rest of the community.
  • Near the beginning of Flickr, Caterina Fake made a point of greeting each new member personally. This is a great idea for making a community feel personal (though I’d be tempted to automate the initial contact, and then respond personally to those who answered.)

It’s food for thought for anyone starting an online community. What tone are we setting, and how will it propogate throughout the platform?