Best Songs, Pt. 7: The Only Moment We Were Alone

August 22, 2019 • #

I still bring out Explosions in the Sky’s 2003 album The Earth Is Not a Cold Dead Place periodically, my favorite from their catalog by a wide margin. I remember seeing them at a live show for the first time on the tour for this album, probably 2004, where they played this song somewhere in the set. In their shows I’ve seen in successive years, it’s one of their encore numbers.

The 6 or 7 crescendos and the build-up to the peak (around the 9 minute mark in this clip) are incredible. The sheer volume of sound that comes out of a few guys with guitars.

On the Tumblr Sale

August 19, 2019 • #

One of the big events in tech last week was that Verizon offloaded Tumblr to Automattic, Matt Mullenweg’s company most known for Wordpress.

I had my main blog/website on Tumblr back when it first launched in 2007, which I used for a number of years before migrating it over to this current self-managed iteration on GitHub back around 20111. At the time I loved Tumblr’s middleground between the long-form-friendly full Wordpress blog and the short-form nature of Twitter. Tumblr’s “tumblelog” concept easily supported either mode depending on what you wanted to post. Their post editor was fantastic (and still is, in my opinion), especially good back in the days before Medium when WYSIWIG editors we’re all pretty terrible. It was the place I learned to use Markdown in everyday writing, which I still use everywhere today, even in my own personal note text files.

Though I haven’t been a user of Tumblr in years, I have some negative and positive feelings about it. The negative is, of course, that Verizon is treating it like a fire sale “write down”, with the previously $1.1bn acquisition in 2013 degrading down to now selling it off to Automattic for a rumored price of “less than $3m”. It’s astonishing that something could lose that much value in the marketplace in such a short period of time.

The upside here is that there’s no better owner and future shepherd of the product than its new one. Automattic has been one of the best community-oriented companies for 15 years, with a publishing platform that powers a quarter of the internet. It’s sad to see it lose so much of it’s former self, but maybe it’ll see a revitalization under new ownership.

  1. I still have that Tumblr account up, but stopped ever posting to it quite a few years ago. 

Weekend Reading: Terrain Mesh, Designing on a Deadline, and Bookshelves

August 17, 2019 • #

🏔 MARTINI: Real-Time RTIN Terrain Mesh

Some cool work from Vladimir Agafonkin on a library for RTIN mesh generation, with an interactive notebook to experiment with it on Observable:

An RTIN mesh consists of only right-angle triangles, which makes it less precise than Delaunay-based TIN meshes, requiring more triangles to approximate the same surface. But RTIN has two significant advantages:

  1. The algorithm generates a hierarchy of all approximations of varying precisions — after running it once, you can quickly retrieve a mesh for any given level of detail.
  2. It’s very fast, making it viable for client-side meshing from raster terrain tiles. Surprisingly, I haven’t found any prior attempts to do it in the browser.

👨🏽‍🎨 Design on a Deadline: How Notion Pulled Itself Back from the Brink of Failure

This is an interesting piece on the Figma blog about Notion and their design process in getting the v1 off the ground a few years ago. I’ve been using Notion for a while and can attest to the craftsmanship in design and user experience. All the effort put in and iterated on really shows in how fluid the whole app feels.

📚 Patrick Collison’s Bookshelf

I’m always a sucker for a curated list of reading recommendations. This one’s from Stripe founder Patrick Collison, who seems to share a lot my interests and curiosities.

Ask Fewer Questions

August 16, 2019 • #

Seneca had great advice 2000 years ago on how to calm ourselves down:

“It is not to your benefit to see and hear everything. Many injuries ought to pass over us; if you ignore them, you get no more injury from them. You want to be less angry? Ask fewer questions.”

I read “ask fewer questions” metaphorically as “don’t feel compelled to engage in every single dialog”. Much of the media discourse fans these flames: show everyone incendiary content, get them annoyed, make it easy to respond, beget another response — an ever increasing turning of the dial toward destructiveness, anger, and negativity.

It’s a daily reminder to, when seeing something that irks you, disengage and redirect attention.

Long Runs

August 15, 2019 • #

When I committed to the half marathon for October, I also enabled one of Strava’s Summit training plans to keep me honest on the times and distances I should be ramping up with as I prep for that race. My personal goal isn’t to hit some target time in the half; it’s mostly to finish in a comfortable time frame. I chose a plan that has a 10-week training course, 4 activities per week with rest days and/or cross-training in between.

Over the last 3 weeks I’ve been trying to manage my activities by duration and heart rate zone rather than just running with no plan. Throughout the year up until now I’ve been doing pretty high paces (sub-8-minute miles), but at that level I can’t keep the times up or the HR in the right “tempo” zone. I’ve been consistent with keeping under the threshold zone for my midweek runs for about 30-45 minute lengths. I’m particularly happy that I’ve gone 3 weeks in a row with long runs on the weekend and hour-long continued effort in the right HR zone.

We’ll see what happens tomorrow and this weekend as I kick off the training plan. It’s set to start next week, so my long run this weekend will be the pre-training benchmark for the 10-week program.

I’ve already crested the +20 mile mark over my year’s goal pace with my increased times and efforts this past month. With this lead up to the half marathon, I could be in the +50 territory by mid-October.

Shipping the Right Product

August 14, 2019 • #

This is one from the archives, originally written for the Fulcrum blog back in early 2017. I thought I’d resurface it here since I’ve been thinking more about continual evolution of our product process. I liked it back when I wrote it; still very relevant and true. It’s good to look back in time to get a sense for my thought process from a couple years ago.

In the software business, a lot of attention gets paid to “shipping” as a badge of honor if you want to be considered an innovator. Like any guiding philosophy, it’s best used as a general rule than as the primary yardstick by which you measure every individual decision. Agile, scrum, TDD, BDD — they’re all excellent practices to keep teams focused on results. After all, the longer you’re polishing your work and _not_ putting it in the hands of users, the _less_ you know about how they’ll be using it once you ship it!

These systems followed as gospel (particularly with larger projects or products) can lead to attention on the how rather than the what — thinking about the process as shipping “lines of code” or what text editor you’re using rather than useful results for users. Loops of user feedback are essential to building the right solution for the problem you’re addressing with your product.

Shipping the right product

Thinking more deeply about aligning the desires to both ship _something_ rapidly while ensuring it aligns with product goals, it brings to mind a few questions to reflect on:

  • What are you shipping?
  • Is what you’re shipping actually useful to your user?
  • How does the structure of your team impact your resulting product?

How can a team iterate and ship fast, while also delivering the product they’re promising to customers, that solves the expressed problem?

Defining product goals

In order to maintain a high tempo of iteration without simply measuring numbers of commits or how many times you push to production each day, the goals need to be oriented around the end result, not the means used to get there. Start by defining what success looks like in terms of the problem to be solved. Harvard Business School professor Clayton Christensen developed the jobs-to-be-done framework to help businesses break down the core linkages between a user and why they use a product or service1. Looking at your product or project through the lens of the “jobs” it does for the consumer helps clarify problems you should be focused on solving.

Most of us that create products have an idea of what we’re trying to achieve, but do we really look at a new feature, new project, or technique and truly tie it back to a specific job a user is expecting to get done? I find it helpful to frequently zoom out from the ground level and take a wider view of all the distinct problems we’re trying to solve for customers. The JTBD concept is helpful to get things like technical architecture out of your way and make sure what’s being built is solving the big problems we set out to solve. All the roadmaps, Gantt charts, and project schedules in the world won’t guarantee that your end result solves a problem2. Your product could become an immaculately built ship that’s sailing in the wrong direction. For more insight into the jobs-to-be-done theory, check out This is Product Management’s excellent interview with its co-creator, Karen Dillon.

Understanding users

On a similar thread as jobs-to-be-done, having a deep understanding of what the user is trying to achieve is essential in defining what to build.

This quote from the article gets to the heart of why it matters to understand with empathy what a user is trying to accomplish, it’s not always about our engineering-minded technical features or bells and whistles:

Jobs are never simply about function — they have powerful social and emotional dimensions.

The only way to unroll what’s driving a user is to have conversations and ask questions. Figure out the relationships between what the problem is and what they think the solution will be. Internally we talk a lot about this as “understanding pain”. People “hire” a product, tool, or person to reduce some sort of pain. Deep questioning to get to the root causes of pain is essential. Often times people want to self-prescribe their solution, which may not be ideal. Just look how often a patient browses WebMD, then goes to the doctor with a preconceived diagnosis, without letting the expert do their job.

On the flip side, product creators need to enter these conversations with an open mind, and avoid creating a solution looking for a problem. Doctors shouldn’t consult patients and make assumptions about the underlying causes of a patient’s symptoms! They’d be in for some serious legal trouble.

Organize the team to reflect goals

One of my favorite ideas in product development comes from Steven Sinofsky, former Microsoft product chief of Office and Windows:

“Don’t ship the org chart.”

Org chart

The salient point being that companies have a tendency to create products that align with areas of responsibility within the company3. However, the user doesn’t care at all about the dividing lines within your company, only the resulting solutions you deliver.

A corollary to this idea is that over time companies naturally begin to look like their customers. It’s clearly evident in the federal contracting space: federal agencies are big, slow, and bureaucratic, and large government contracting companies start to reflect these qualities in their own products, services, and org structures.

With our product, we see three primary points to make sure our product fits the set of problems we’re solving for customers:

  • For some, a toolbox — For small teams with focused problems, Fulcrum should be seamless to set up, purchase, and self-manage. Users should begin relieving their pains immediately.
  • For others, a total solution — For large enterprises with diverse use cases and many stakeholders, Fulcrum can be set up as a total turnkey solution for the customer’s management team to administer. Our team of in-house experts consults with the customer for training and on-boarding, and the customer ends up with a full solution and the toolbox.
  • Integrations as the “glue” — Customers large and small have systems of record and reporting requirements with which Fulcrum needs to integrate. Sometimes this is simple, sometimes very complex. But always the final outcome is a unique capability that can’t be had another way without building their own software from scratch.

Though we’re still a small team, we’ve tried to build up the functional areas around these objectives. As we advance the product and grow the team, it’s important to keep this in mind so that we’re still able to match our solution to customer problems.

For more on this topic, Sinofsky’s post on “Functional vs. Unit Organizations” analyzes the pros, cons, and trade offs of different org structures and the impacts on product. A great read.

Continued reflection, onward and upward 📈

In order to stay ahead of the curve and Always Be Shipping (the Right Product), it’s important to measure user results, constantly and honestly. The assumption should be that any feature could and should be improved, if we know enough from empirical evidence how we can make those improvements. With this sort of continuous reflection on the process, hopefully we’ll keep shipping the Right Product to our users.

  1. Christensen is most well known for his work on disruption theory

  2. Not to discount the value of team planning. It’s a crucial component of efficiency. My point is the clean Gantt chart on its own isn’t solving a customer problem! 

  3. Of course this problem is only minor in small companies. It’s of much greater concern to the Amazons and Microsofts of the world.