Menu

Tracking development uncertainty with hill charts

I read something recently that struck me as a really good idea for our team. Usually that feeling goes away after a couple of hours (“nah, it’s cool but not a good fit for us”) — but not this time. In Running in Circles, Ryan Singer talks about the knowns/unknowns in a project like a hill:

The most important question for a team isn’t “what is left?” but “what is unknown?” Can you see the edges? Have you gone in there and seen everything that needs to change? The only way to gain certainty is to roll up your sleeves and engage with the reality of problem.

At Basecamp our teams seek out the areas with the scariest unknowns and work on them first. This uphill work requires strategies. We wrote about these in Getting Real. Open the code, spike something that works, load it with real data and try it. When the whole feature is too big to prototype, factor out the most important pieces and spike them.

He has a a nice visualization of it:

He also uses an example from a recent project to show how they map this out:

As they “move over the hill”, different parts of the project become known, and they become more certain about what’s left to do. We’re working on some checklists to identify development risks before we start a project, and this looks like a great way to visualize those risks and track them as you go.

Social internet, social media, and the move to smaller networks

I should stop reading (and writing) about Facebook at some point, but there’s been some really interesting thinking around the social internet in general recently. I especially enjoyed Benedict Evans’s The death of the newsfeed, because it puts into words a lot of things I’ve been thinking about. On the social implications of algorithmic feeds:

One basic problem here is that if the feed is focused on ‘what do I want to see?’, then it cannot be focused on ‘what do my friends want (or need) me to see?’ Sometimes this is the same thing – my friend and I both want me to see that they’re throwing a party tonight. But if every feed is a sample, then a user has no way to know who will see their post. Indeed, conceptually one might suggest that they have no way to know if anyone will see this post.

This is one of the major flaws of algorithmic feeds. People share things so that those things can be seen. But if you can’t tell who will see the things you share, that’s frustrating, and more than a little nerve-wracking. Hence the move back to smaller networks:

I think one could suggest that this is some of what’s behind the suggestions of systemically lower engagement on Facebook newsfeeds, and behind the obvious growth of person-to person chat (most obviously WhatsApp, iMessage, FB Messenger and Instagram – three of which Facebook of course owns). The social dynamics of a 1:1 chat work much more strongly against overload, and even if one person does overshare they’re in a separate box, that you can mute if you like. […]

Messaging can be more private, have less social pressure, and be more fun. A Snapchat story isn’t a permanent record and has less pressure to show off your perfection. Stickers and filters are more fun and spontaneous than Facebook’s rigid blue boxes (and the days of throwing sheep at people are gone alone with Facebooks’ platform). And some of these offer light-weight ways to interact without obligation, which was also a feature of Facebook’s model, but deliver that piece of Maslow in different ways.


On that note, I think the distinction Cal Newport draws in On Social Media and Its Discontents is really important:

There’s a distinction between the social internet and social media.

The social internet describes the general ways in which the global communication network and open protocols known as “the internet” enable good things like connecting people, spreading information, and supporting expression and activism.

Social media, by contrast, describes the attempt to privatize these capabilities by large companies within the newly emerged algorithmic attention economy, a particularly virulent strain of the attention sector that leverages personal data and sophisticated algorithms to ruthlessly siphon users’ cognitive capital.


In the final analysis, I agree with Cal:

I support the social internet. I’m incredibly wary of social media.

Why you should (usually) choose boring technology

This is a fairly old post, but I only recently came across Dan McKinley’s Choose Boring Technology. It is so good.

What counts as boring? That’s a little tricky. “Boring” should not be conflated with “bad.” There is technology out there that is both boring and bad. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.

The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.

He goes on to explain the process you should go through before you try out a new technology.

The humble product manager

When the design community wants to argue about something they fall back on the age-old question, “Should designers learn to code?” In the same way, for as long as the role has existed, the product management community has debated whether or not PMs should be referred to as “the CEO of the product.”

Neither debate will ever be settled — this is just something we do. But Marty Cagan does have a solid addition to this never-ending argument in his post CEO of the Product Revisited. His main point is this:

Now, the strong product manager does not need to be an expert in all of these many aspects of the business, any more than the CEO needs to be.

The key is that, like the CEO, the product manager needs to have a solid understanding of the many aspects of the business, and assimilate all of this information to make informed decisions.

But it is his focus on humility that I want to spend a moment of reflection on:

So going forward I’m going to continue to emphasize the importance of humility and earning the team’s trust, but I will also start emphasizing and embracing the positive aspects of the similarities of the PM role to the CEO.

A call for humility in product management is not something I see very often. This is strange to me, because I find this to be an extraordinarily humbling profession. There is so much to learn and do that I am not sure how anyone can think of themselves as an “expert” in the product role.

At one extreme, PMs need to be confident about the decisions they make. They need to keep learning and growing, and hone their craft constantly. Solid theory and excellent technique need to become so ingrained that they simply become second nature, cornerstones of everything they do.

But equally important — and this is why humility is so important — they need to be open to the possibility that some of their decisions might be wrong. They should hang on to a measure of self-doubt every time they present a new solution to the team or the world. Admitting that someone else’s ideas are better than your own, and making changes based on good critique do wonders to improve products — and build trust within the team.

In the design context John Lilly phrases this in a way that should become a mantra for all product managers: “Design like you’re right; listen like you’re wrong.”

More evidence of the ways technology can be bad for our health

Stories about how technology can be bad for our health is not new, of course. But two articles in this particular genre caught my attention this week. The first is some HBR research showing that Having Your Smartphone Nearby Takes a Toll on Your Thinking (Even When It’s Silent and Facedown):

The mere presence of our smartphones is like the sound of our names or a crying baby — something that automatically exerts a gravitational pull on our attention. Resisting that pull takes a cognitive toll.

A bit more about that “gravitational pull”:

Research in cognitive psychology shows that humans learn to automatically pay attention to things that are habitually relevant to them, even when they are focused on a different task. For example, even if we are actively engaged in a conversation, we will turn our heads when someone says our name across the room. Similarly, parents automatically attend to the sight or sound of a baby’s cry.


In another article, Virginia Heffernan explores the question What Are Screens Doing to Our Eyes—And Our Ability to See?:

Having recently, in my forties, gotten reading glasses, I now find myself having to choose between reading and being, since I can’t read without them and I can’t see the world with them. The glasses date from a time when reading was much rarer a pastime than being; you’d grope for them to see a book, while relying on your naked eyes for driving, talking, walking.

There is no “solution” to this, but as someone who also has reading glasses, I do like her approach to make this weird feeling a little better:

When I pull away from the screen to stare into the middle distance for a spell, I take off my glasses. I try to find a tree. If I’m inside, I open a window; if I’m outside, I will even approach a tree. I don’t want mediation or glass. The trees are still strangers; I hardly know their names yet, but I’m testing myself on leaf shapes and shades of green. All I know so far is that trees are very unlike screens. They’re a prodigious interface. Very buggy. When my eyes settle after a minute or two, I—what’s that expression, “the scales fell from my eyes”? It’s almost, at times, like that.

Easier blog post image management with Dropshare and Amazon S3

I’m always on the lookout for faster ways to upload and insert images into blog posts. It’s the part of the blogging workflow that I dislike the most. Up to now I’ve used a pretty convoluted combination of Amazon S3 buckets and Transmit. But over the weekend, while moving hosting providers1, I finally came up with a really simple image upload workflow that I thought I’d share in case it helps anyone else.

This workflow lets you drag and drop an image to a menu bar icon on your Mac, and then immediately paste a secure, custom domain URL for that image wherever you need it.


Step 1 – Create S3 bucket

Create an Amazon S3 bucket for your image uploads. It doesn’t matter what you name the bucket, but do not add a . to the name. This creates some weird SSL certificate errors later in the process that you don’t want to deal with.

Also make sure you set the bucket to be publicly accessible via the Permissions tab, otherwise you’ll get read errors for your files.

Step 2 – Create CloudFront distribution

Create an Amazon CloudFront distribution for the S3 bucket you just created, so that you can use a custom URL for your images, and make use of Amazon’s Content Delivery Network (CDN) capabilities.

When you go through the flow of adding a distribution for your S3 bucket, leave the “Distribution Settings” section blank at first — we’ll come back to that.

CloudFront settings

Step 3 – Add custom domain for your images

Back on the main Distributions screen, note the CloudFront domain name that was created for your bucket. It’s going to be in the format ***************.cloudfront.net. Go to your DNS provider and add a CNAME for the custom domain you want to use for your images.

In my case, cdn.elezea.com points to my CloudFront distribution at d26fqxuc6*****.cloudfront.net, which in turn links to the S3 bucket I set up earlier.

Step 4 – Add SSL certificate to CloudFront distribution

Now go back to your Distribution Settings in CloudFront. Add your CNAME information, and then click the button to “Request or Import a Certificate with ACM”.

This will take you through the process of generating a free SSL cert to be used with your CloudFront distribution. This is essential if you serve your site over https. If you don’t do this, your images will be served over http and you will get “mixed content” warnings when you embed images in your site.

Change your settings to “Custom SSL Certificate”, and you’re good to go.

CloudFront settings

Interlude – take a breath

If you’ve successfully completed these steps, here’s where you’ll be. Whenever you upload an image to your S3 bucket, you will be able to serve that image via your custom URL over https, and as an added bonus, you’ll be using Amazon’s CDN for super fast delivery.

Now we need to figure out the fastest way to get images into that bucket of yours.


Step 5 – Download and set up Dropshare

There are many sophisticated ways to manage your S3 buckets. But when it comes to uploading an image and getting a URL for it, I haven’t found anything that’s simpler than Dropshare.

In short, Dropshare allows you to establish connections to all your S3 buckets. It lets you upload files by dragging them to the Dropshare menu bar icon, and then the URL for that image is automatically copied to your clipboard. So to add an image to this blog post, for example, I just drag the image to the menu bar icon, then come back to where I’m writing and ⌘-V to insert the link. It couldn’t be easier.

I have a bunch of S3 buckets linked up in Dropshare:

Dropshare

In the case of the bucket I use for this site, note that I entered the bucket name, the domain alias (the CNAME you added earlier), and that I have the “Use SSL” box checked:

Drophsare

This makes the workflow for adding images an absolute breeze. Drag and paste. That’s it.

When you upload an image, Dropshare lets you choose the bucket you want to upload to, as well as if you want to add a landing page and/or use a URL shortener (which I usually don’t, but it’s nice to have the option).

Drophsare

Dropshare is useful for other things too. I have a keyboard shortcut that takes a screen shot, automatically uploads it to an S3 bucket, and copies the URL to the clipboard. That’s great for sharing screen shots in Slack, for example.


I’m not sure how many people have this need to shave a few minutes off their image workflow. But I hope this post is useful for the few of you who do obsess about things like this, like I do. And please let me know if you think this flow can be improved even more!


  1. I’m now with DreamHost and much happier. 

Product management for maturing products

Janna Bastow wrote a great post on product management for maturing products. From Growing up Lean: Lean Strategies for Maturing Products, here’s a recommendation for how to avoid becoming a “Feature Factory”:

Break the backlog up into two parts: The Product Backlog and the Development Backlog. […]

Product Backlog: A list of all of the things you could do. You’ll never complete everything on this list, and it’ll always be in a constant state of flux. It’ll include customer requests, suggestions from your team, through to insights from your experiments and prototypes. It should be accessible by your team, to both contribute and follow along on progress – your team should be helping to build and flesh out the ideas in your backlog. This is your space to prototype and spec out ideas, map them to your objectives, and track their progress until ready for production.

This is similar to how we do things at Postmark. Here is our Releases board in JIRA:

JIRA releases board

You’ll see that we have our short-term planning (the Development Backlog), that currently only covers 2018.2 and 2018.3 (roughly 6 weeks each). And then we have the mysterious Later release… that’s the Product Backlog. It’s that list of all the things we could do. When we do short-term planning we pull from that list, as well as other areas (most notably, our “Idea Zone” in Basecamp, which I should also write about at some point).


I’ve written about maturing products before as well. I’m happy to see that Jenna and I bring up similar points. Here’s a quote from my post Product Management for well-established products, which echoes some of her thoughts:

With an established product, it’s way too easy to get off track (Evernote, anyone…?). So what I argue for is a flexible quarterly roadmap of prioritized themes. You don’t write down dates next to a long list of features. You don’t make hard commitments for releases that might never happen.

Instead, you put together a list of themes you’d like to work on, in order of priority, based on how closely they align with your objectives and key results for the quarter.

Craig Mod on the revival of print and why it’s important to go offline

Oh boy, where to begin with Craig Mod’s interview with Offscreen Magazine. I’ve been following Craig’s work for a long time, so I have an undeniable bias towards everything he does. But some of the things he says in this interview touched a deep nerve for me, as it relates to a lot of what I’ve been thinking about lately.

It’s a long interview, and you should absolutely take the time to read it all. I’ll just post a couple of my favorite quotes here.


On the revival of print and other analog technologies:

I think books are the perfect disconnected objects. They require no energy. They offer a fully immersive, quiet experience for hours or days. The medium dissolves but never becomes translucent. It’s quiet, but present. An exceptional technology.

When you sit down with a book, you understand the parameters of engagement. You know how long the book is. The book isn’t changing as you read it. It’s a solid, immutable thing. You and the book are on equal terms in many ways, as least from a physics point of view. You know what’s going to happen, and the book abides by its implicit contract, which is to be a book.

However, in digital-land many spaces (apps, games) quickly turn into slithering creatures beneath your feet. You never know where you stand. Their worlds are optimized to pull you back in for one more minute, one more click. Over and over. Cascades of chemical reactions in your noggin’ tell you to keep going, just one more hit; I feel this persona of the addict very strongly when I am online or using certain apps or devices.


On your life’s work and what moves you:

Does affecting one hundred lives turn you on? A thousand? A million? A billion? Why? What does it mean to have a positive impact on a life? How intimate does that connection need to be? Understanding your scale — the scale that moves you — is critical to understanding with whom and how you should work, how you should live.


On always being online:

The default expectation today is “always available.” The systems we created are so frictionless that we haven’t noticed how insidiously over-engaged we are. Step by step we’re optimizing ourselves to “maximum” productivity without defining or thinking about “productivity” on a human scale. The digital world abstracts. One could argue most problems contemporary society faces are problems of over-abstraction. As an employer with a global workforce, you have no idea where your employees might be or what they might be doing, so you expect them to answer immediately. The concept of downtime is elusive.


And finally, on “edges”, a topic he’s written about a lot:

Edges ground us. Without clear edges we don’t feel like we’re in control.

Craig Mod - Offscreen Magazine Interview

More

  1. 1
  2. ...
  3. 56
  4. 57
  5. 58
  6. 59
  7. 60
  8. ...
  9. 202