AirPods Pro: A quick review

Short version: this is the best product Apple has ever shipped.

My credentials on this: I’ve been using Apple products since the Mac SE and Apple IIe. I’ve had a Mac in every major processor generation since the 68k, most of the iPods, most iPads and every iPhone except the latest one.

Clearly I love a lot about how Apple does their work.

But this is the pinnacle of their abilities: a hyper miniaturized, super futuristic, intensely satisfying piece of personal hardware.

First, let’s hit the deltas with the original. They don’t look stupid anymore. Look, I loved the original but they looked a little stupid. The stems were too long. We all got used to it and it didn’t matter because the hardware was otherwise so convenient and easy to use.

But now the proportions look great. The stems are nicely balanced against the rest of the unit.

Of greater importance, though, is the elimination of seams on the buds. The old model would get fucking nasty, building up gunk in its seams. In the new version, there’s minimal gap between the white plastic and the black housings for microphones and sensors.

They’ve moved the indicator light to the front face instead of inside the lid. This is nice—great to know at a glance if they’re done charging.

Now, the new stuff.

Their magic valves are amazing. I don’t understand how the fuck this works but it works: you put the AirPod in, and then it equalizes pressure so that the rubber cup seals against your ears without trapping air inside uncomfortably. This alone destroys all competition in the rubber-cupped earbud space. I’ve never had anything so reliably comfortable also go in my ear.

The noise cancellation is truly impressive. It just cleans things up so well. John Gruber noted this in his review: you can use them without music to enjoy silence wherever you are. It’s really nice. If I still worked in open plan offices, I would submit an expense report with these on it and go to the mat for their indispensable value.

Speaking of rubber cups, it’s impressive how they snap into place. You know they’re seated properly. It’s a very tactile experience. Feels great, and yet again, just destroys the incumbent rubber cup bullshit gang. Replacements are $4. These also make the buds so much easier to clean compared to the gunk scoops on the last model. Each cup has its own screen to prevent crud entering the speaker chamber it covers.

I love them for music as much as voice calls. I can hear myself clearly despite the rubber cups and my correspondent sounds like they’re in a quiet room with me.

One gripe: the things are just supposed to die when their battery does? I wish Apple would make the batteries replaceable. I’m not sure how to make that work against the miniaturization at play, but it seems worth doing. I bought the Apple Care+ for $30 because I know I’ll destroy these batteries inside two years. That will give me a free replacement when it happens, assuming I don’t lose them.

Since the iPhone, my read on Apple has been that they create futuristic, science fiction artifacts that you can buy right now. The iPhone 4 was a perfect example, and these AirPods Pro are another. They just seem impossible, but they’re quite real.

After Cook took over, there was much handwringing about whether he’d be able to ship the sort of detail oriented, aesthetic-defining, delight-inspiring work that put Apple on the map. I think this answers that quite definitively.

Worth every dollar.

Post Mortem: Digamo Beta

I’m excited to share a new project with you. It’s called Digamo and it’s a macOS app built for people who have, or should have, 1:1 meetings at work.

Digamo is a collaboration with my dear friend, podcast co-host, and occasional boss, Nicole Sanchez. It’s something we’ve been thinking about doing for years. Back in April, we decided to go for it.

What the research said

Before diving headlong into development on a project we were both excited to build, though, I asked Nicole to conduct some user research. We had some strong convictions already:

  • Managers didn’t often get the support or training they needed to do their best work
  • Healthy, regular communication, especially between bosses and their reports, was essential to inclusion
  • We could improve both of these situations by creating structure and guidance for common workplace communication through software

We still believe these things. But if we were going to invest the energy and effort needed to produce a whole software product, I wanted more information from the sort of people we wanted to serve.

Nicole gamely conducted interviews with people managers, digging into their processes for communication and how they managed the many meetings and conversations that were essential to their daily work. One theme emerged clearly:

Many managers had an enormous Google Doc they were using to keep track of… everything. The text was monstrous and unstructured. Things often got lost over the longer term.

This was an opportunity we hadn’t considered, but it fit into our goals well: software could also structure the information that emerged from these conversations. This would make it possible to slice, filter, search and summarize that information at a later date. In addition to training managers on good communication, and encouraging that communication, we could also provide value by capturing and summarizing outcomes.

This insight was a North Star that guided our product development, and we share it eagerly with you. People are drowning in information. Help them organize it better, you’ll make a better workplace.

Starting development

At first, we weren’t sure how eager people would be for yet another piece of software at work. We started with the goal of reaching an alpha that would run on an iPhone, sync with your work calendar, and help you prepare for meetings.

The idea here was that we could meet our users in their spare time, relieving their anxiety about upcoming meetings by providing a clear structure for the sorts of things you do before and after sitting down. You might have some decisions that you want to make sure are made by those in attendance. We suggested warmup activities to build rapport between attendees. How will you know the meeting was successful?

We prompted the user to think about, and write down, responses for all of these and more. A neat party trick was that the output was nicely formatted into an agenda you could email.

There was just one problem: the iPhone was a bad fit for these tasks. No one wanted to look at their phone in the middle of a meeting, and prepping for meetings just isn’t the sort of casual task anyone is eager to do with their thumbs.

And we were about to have company.

~Validating the market~

When competitors join the scene, it’s Silicon Valley tradition to smile fixedly and announce how excited you are to see them validate the market. There’s some truth to this posturing, though: it’s encouraging to see others converge on a conclusion you’ve reached on your own. Maybe the timing is right for your idea.

We took the validation to mean we could dispense with the idea of building this as an iPhone toy. We would proceed as though the world was ready for another piece of workplace software.

Still, no amount of business aphorisms would change that we were now approaching a problem alongside teams that were bigger and better-capitalized than we were. Moving to a desktop format would help our project be taken seriously, but we were still outgunned.

For our vision to have a future, we would need to chart an unconventional course. As the sole engineer on the project, it was my job to make things work while keeping things lean. If people were going to use this on the job, it had to be sturdy and reliable. And we had to ship quickly, with competition around the corner. These are interesting constraints to manage when your developer bus factor is one.

What are the decisions only we would make?

As outsiders, Nicole and I had little hope of raising money for this project without showing significant progress, so that ruled out bringing on more engineers. Without a larger crew, I didn’t feel confident in using web technology for something so mission critical. I’d be tied to my keyboard indefinitely, protecting the infrastructure that kept the product alive.

So we tried something different: decentralizing our software entirely. Our approach turned to a native macOS application that would host and maintain all its own data.

Gif: Man points knowing at his head and grins.
Server can’t go down if you don’t have a server.

Because we weren’t starting with non-negotiable hyper growth as a requirement, this old-fashioned approach would be viable for us. The more we explored it, the better it fit our values. By designing our project without a centralized server infrastructure, we could guarantee that no one else surveilled your usage of it. This was important because we wanted our users to be real about the thorny communication issues they encountered at work. We wanted them to trust our product the way they would their own physical notebook.

I’ve seen complex, misconfigured workplace software that leaks sensitive details like a sieve. It’s a privacy nightmare. Our approach sidestepped all of that.

We also got some practical benefits: the application could run locally without needing to package an entire web browser under the hood, so the binary size is just 20 MB. The native code is also efficient. Even with a large data set, it doesn’t seem to need more than 50-100 MB of system RAM. So, as a bonus, we got a minimal resource footprint and the ability to run without an internet connection thanks to building a native desktop app.

For object graph maintenance and persistence, the app uses Apple’s Core Data framework. Ten years after my first Core Data projects, I’m impressed with how much easier it is to work with these days. The framework still has a meaningful learning curve and I’d be bullshitting you if I said I grasped all its complexities. Nonetheless, I found it a straightforward way to maintain all of Digamo’s relationships and generate the user-specified queries needed for summarizing data.

As a long time iOS developer, I have to take a moment to gush about Cocoa Bindings. They make UI development so fast and easy. With the advent of SwiftUI, they may be destined for sunset. I’m glad I finally got a chance to use them, after years of envy from afar.

We still ended up with a lightweight server to provide automatic updates, delivered by the excellent Sparkle Project. This is just good practice if you’re distributing outside the App Store, but it’s also essential for a beta. Our users will always have access to the latest features if they opt-in to these updates. Still, the server could go down for a weekend and no one’s work would be interrupted.

Reaching the home stretch

Meanwhile, Nicole’s work in the field was yielding some interesting feedback.

In her capacity as an expert in organizational design and workplace culture, Nicole spends a lot of time training leaders in the basics of good management. She had this slide:

Spreadsheet depicting a grid of multiple categories of data to collect during 1:1 meetings.

People were grasping at it more than anything else in her trainings. Just a simple spreadsheet, but it offered so much clarity about how to consistently do 1:1 meetings. Weeks after their first introduction, people were still using spreadsheet as part of their ongoing work.

We had our product.

Screenshot showing Digamo's note input interface

From there, we dumped the complexity of calendar syncing and meeting prep. Our laser focus was one thing: supporting 1:1 meetings. Setting expectations for the topics people should cover, helping them keep track of how often they discuss things like feedback, professional goals, time off, major wins, and more—not to mention helping our users dig up those discussion notes later on.

Screenshot of Digamo's sentiment capture interface

Nicole’s spreadsheet also asked people to keep track of sentiment, and we worked together to find a structure for this fuzzy data so that we could surface it in the UI.

Screenshot of Digamo's emoji timeline

Each teammate gets their own emoji timeline, showing the progression of their sentiments over time. We can also give you a bird’s-eye view of sentiment across your team at any given moment, as the teammate selector list view displays a summary of the most recent entry. That view also flags any teammates who have been neglected in your 1:1 meetings, always showing people with meetings furthest in the past at the top of the list.

Screenshot of Digamo's teammate list

Emojis are subjective, so it’s possible to set your own preferences for them, too.

Screenshot of Digamo's emoji preference panel

With all this data structured, it’s easy to retrieve later on. Just choose a teammate, a time frame, and the notes you care about, and Digamo will generate a summary. We can also do the same with your whole team. We know how much work performance review season can be. We’re excited to see how this feature helps streamline those processes, reminding you of the full picture of your team’s challenges and accomplishments.

Screenshot of Digamo's summary generator.

So that’s Digamo. It’s your private, digital notebook for recording 1:1 meetings. Thanks to the Vaya Consulting team, and especially our friend Dr. Nick Bedo, for the support in getting this out the door.

Hidden in the product are a handful of deliberate bias mitigation strategies:

  • Summaries help mitigate recency bias, surfacing details you might have forgotten in the day-to-day maelstrom of surviving work.
  • The teammate list really wants you to see anyone whose 1:1’s you’ve been dodging.
  • By collecting your sentiments, in addition to those of your 1:1 counterparts, Digamo can help you compare how you’re engaging with one teammate versus another.

What’s next?

There’s so much more we want to do with Digamo, but it’s time to get it out into the world. High on the list are things like automated backups, sync with other devices, and a return of calendar sync. We’ll get there. Meanwhile, we’ve got the start of something a lot of folks have been asking us for. We hope the structure and conveniences provided by this initial beta will be helpful in your daily work.

While a lot of the people we know use a Mac, we know a macOS app doesn’t cover the full spectrum of people who need this product. We’ll be thinking about how to deliver this more broadly in the future.

Meanwhile, Digamo is free to download and use while we develop it further. Download it here.

Are you an investor who wants to help us deliver workplace technology like this for more people and more use cases? Get in touch.

How to Ship a Software Project

I’ve spent the last 14 years building software, off and on. Over that period I’ve been on the hook for dozens of ship dates. Some I missed. Many I hit.

Through all those adventures, I’ve settled on a basic process I think anyone can use to get from deep-in-the-weeds to a triumphant ship. None of this is especially innovative. Plenty of people likely ship using some variation of this exact procedure. But I wanted to write it up in case it was useful.

1. Pick a ship date—but don’t get attached to it

Start by choosing a date on which it would be nice to have shipped your project. Any criteria is valid here. Business needs, deadlines imposed by programs to which you want to apply, even press strategy.

But don’t get too attached to this ship date. You have no idea if you can make it. At this point it’s an experimental constraint, which will guide the rest of your planning process.

2. Determine the minimally viable feature set your project needs for a successful ship

What does the audience of your project need to be better off than if you’d never shipped the project at all? What is the simplest feature set you can deliver to make an impact?

by Henrik Crisp

You’re reading this because, presumably, you would like to ship. So it’s essential you understand that you can’t immediately ship everything your mind imagines. You can’t ship perfection. Perfection and shipping hate one another, so you have to pick one. I suggest picking ship, but that’s up to you.

Shipping requires hard choices. The more things you try to bundle into a shipping project, the more risk you incur. The risk multiplies invisibly, as it’s impossible to know ahead of time about complex interactions that produce bugs, reduce performance, or otherwise introduce surprises.

The fewer things you try to ship at once, the less risk you incur. So when you make the list of things you want to see in your first ship, do everything you can to keep it as short as possible.

3. List all of the dependencies that must be satisfied for your minimally viable feature set

What needs to exist for these features to work? How much already exists? Get your mind around all the dependent tasks, from things that need to be built, to things that must be bought, to things that must be designed, in order for these features to be ready for public consumption. With luck, you’ve already got some of these dependencies handled.

Can you license or purchase things instead of building them yourself? Can you leverage open source software rather than rolling your own solutions? Think through how many off-the-shelf opportunities exist to satisfy your dependencies. But also remember there’s no free lunch: integrating outside resources can still be costly.

4. Estimate how much time it will take to satisfy your dependencies—then multiply

Software development time estimates are comically error-prone. But if you price the estimation risk into your estimate, you can earn yourself some breathing room. There will be bugs that keep coming back. There will be surprises as you integrate third-party tools and content. There will be tasks that seemed easy at the outset, but whose implementation reveals a raft of additional complexity.

That’s life in the software business.

As you create an inventory of your dependencies and the time you estimate they’ll need to cook, multiply by 2.5.

Maybe that seems excessive. But it’s a concession to the fact that our frail meat brains are bad at storing and modeling the total complexity of a software system. When you made your initial guess, you were quite possibly ignoring more than half the picture. Price that limited perspective into your final guess.

Or don’t. It’s your ship. You can use whatever multiple you feel comfortable with here. Long experience tells me that for my estimates, though, I usually want 2.5x.

Don’t forget time for testing your project ahead of ship. I can’t tell you how long this will take, since different environments have different constraints. If you’re shipping native code for approval in the iOS App Store, for example, you’ll want to do much more thorough testing than if you’re shipping a web app you can update at-will.

You’ll also want to budget time to make fixes based on what you learn in the QA process.

5. Add up your time estimates and compare the timeline to your ship date

If you’re very lucky, your time estimates and your ship date mesh perfectly.

But you’re probably not lucky. You’re working with software, and software delights in thwarting our optimism. What if your requirements push far past the ship date?

You’re going to be tempted to manipulate the estimates. Don’t do this. There’s a reason we estimate in pieces and add things up, instead of working backwards from the ship date.

In this process, here are all the things we’ve considered in order from most real to least real:

  1. The dependencies for our desired features
  2. The minimally viable feature set
  3. The time estimates
  4. The ship date

The ship date is the least real thing we’re dealing with! Don’t let it drive.

That said, if you absolutely must treat the ship date as a hard constraint, you have options. None of them include goosing the estimates.

6. Make hard choices: trim scope or move the ship date

I know. You want a pony.

🗓💰

But now you know what the pony costs.

You’re going to ship the pony 18 months later than you would have liked. Are you going to have enough money to survive for that extra 18 months? Will you give up an important competitive advantage by taking that extra 18 months? Are you OK waiting 18 extra months before getting feedback from customers about whether you’re even on the right track?

Maybe you’re fine moving the ship date. Sometimes that’s the right call.

But often, this is the point in the exercise where you take out your knife and start trimming scope. Maybe you’re not going to ship a pony. Maybe it’s time to ship a bicycle instead. With the knowledge of the time and financial cost of your minimally viable feature set, maybe you can find inspiration to pare down even more.

Trim scope until your estimates for the remaining work—which you have not goosed—give you a few days of margin under your ship date.

Now you can get to work, having a clear idea of what’s worth prioritizing and what can wait. You can repeat this process whenever you feel your project getting off track or losing steam. It helps me to track my requirements and dependencies on something tactile, like notecards or sticky notes, but you can document the process you’ve gone through using whatever systems make sense for you and your team.

But, Danilo, this isn’t the agile/scrum/[cargo cult methodology] way!

Whatever, man. I’m sure it isn’t. This is the way I know to get a project out the door on a date agreed upon by all parties, with scope documented for all parties, with trade-offs understood by all parties.

Within that, I’ve seen it work alongside tools like sprints, planning meetings, stand-ups, and retrospectives. I really like doing all of those. If you have existing systems you like to use to communicate and collaborate, you can keep them.

But you need a way to understand the relationship between costs, scope and outcomes, and to communicate those constraints across all functions. This is the basic approach I’ve long used for that. I hope it’s helpful in your adventures.


Further reading:

1.0 by Rands: “Shipping a 1.0 product isn’t going to kill you, but it will try.”