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.”

Why Apple chooses thin devices over longer battery life

Apple is never happier than when announcing a flagship product has been made just a little thinner.

It happened last week with the Apple Watch, which is 0.7mm thinner than its predecessors. Before that, the iPhone lost more than half its thickness over the course of a decade. The iPad has slimmed down significantly from its first iteration. And who could forget the introduction of the MacBook Air, plucked with fanfare from a manilla envelope.

Steve Jobs loved a good reveal.

Every time this happens, you can set your watch by a chorus of onlookers and faithful Apple customers both asking the same thing:

Why can’t we have a few more hours of battery life instead?

With all the extra volume Apple’s miniaturizations have carved out over the last ten years, it’s conceivable they could have doubled the battery capacity of their most popular products. Smaller components means the possibility of more room to store energy.

Instead, we get a march toward smaller and lighter devices.

There’s a strategic reason for this which can teach us a lot about 21st century economics.

Information goods

Information technology pervades every aspect of our culture and economy. Even physical products now have deep information roots. As Paul Mason’s Postcapitalism describes:

In hi-tech engineering, before a single piece of metal is shaped, objects are designed virtually, tested virtually and even ‘manufactured’ virtually — the whole process modelled from start to finish — on computers. The mistakes are discovered and rectified at the design stage, in a way that was impossible before 3D simulations came about.

Which means that the outcome of a research and development process can now be cheaply duplicated by anyone who has access to the basic machinery to convert digital plans and schematics into finished goods. Competitors can produce alternatives or counterfeits that cost little more than the raw materials, tools and labor necessary. Because these competitors have minimal R&D costs, they can undercut the original producer, destroying their profit margins.

In Mason’s words, information tech “corrodes” prices over the long term.

Many who shop on Amazon or Ebay have first hand experience with this phenomenon. Both services are rife with counterfeits sold as the genuine products of the brands they’re emulating, often at discount. This presents meaningful challenges for small companies selling basic hardware. Elevation Lab designed a clever but easy to manufacture hook for storing headphones beneath your desk. They quickly found themselves competing with counterfeiters:

They literally reverse engineered it, made steel compression molds, made the logo wrong, used fake 3M adhesive that’s very thin and was diecut smaller than the top (measure once, cut twice), they use a lower durometer silicone so it flexes more, its has huge mold parting lines, and the packaging is literally photocopied then reprinted (you can tell by the lack of image contrast). And they had to apply a big sticker to cover our SKU with theirs. But to the untrained eye, it would pass.

Elevation Lab was unable to maintain a monopoly on the basic inputs that yielded their product. The design schematics, manufacturing tooling, and even packaging could be approximated by a third party wielding the power of information-based design and production.

It is into this future that Apple is sailing.

Apple’s monopolies

Here it is helpful to define our terms.

Monopoly is a loaded word. The Bell Telephone Company once held an absolute monopoly on all US telephone service. Microsoft had a monopoly on computer software in the workplace, controlling more than 90% of desktops in the 1990’s.

But monopoly can exist even without this level of market dominance. You can be the exclusive purveyor of a product without being the exclusive purveyor to an entire market.

This is the position where Apple finds itself. It doesn’t come close to selling all of the world’s smartphones.

Yet it maintains a tight control over several inputs that make an iPhone:

  • iOS, the operating system that drives all its non-Mac computers
  • Their processes and designs for creating the custom chips that now drive the iPhone
  • Expert hardware engineers who can push the state of the art into new scales
  • Processes, equipment and raw materials for producing consumer hardware at extraordinary scale, to extremely fine tolerances.

Miniaturization as monopoly

So why is Apple making things thinner, rather than expanding battery life? Why are they sacrificing headphone ports to push their designs into thinner and thinner dimensions?

The answer is that anyone can make bulky tech with massive battery capacity.

But no one can build devices that are as miniaturized as Apple’s.

Through miniaturization, Apple creates products whose subjective experience of niceness cannot be matched. By exclusive control of cutting edge, global-scale manufacturing processes and the silicon necessary to produce both powerful performance and good enough battery life, coupled with an exclusive operating system written to match and enhance the capabilities of the hardware, only Apple can make iPhones.

Which means if you want a phone that feels this nice, you have to pay prices set exclusively by Apple.

Apple is staking its future on its ability to make products that are seamlessly integrated and ever smaller, lighter, and thinner. For now, it’s working. They’re worth a trillion dollars. As manufacturing processes advance and evolve, Apple will have to evolve along with them.