This blog is going away soon! :( Check out my new site where you can read the latest and subscribe for updates!

In addition to my day career, I’ve also done audio engineering work for the last 11 years or so. This has ranged from volunteer/amateur work up through the occasional professional gig. Much of it was live mixing, but in the days of COVID-19 I do a lot more recorded mixing.

The most common request I get - mostly back in the days where I was still learning, or early at a gig where I’m still dialing in the mix - is “hey, can you turn up the volume on instrument/person XYZ?”

It’s a perfectly reasonable request. I cannot be in all places of the room at the same time, and I’m not creating a mix for myself, so feedback from staff/musicians/the crowd is invaluable to get it right.

Except for one detail. Fulfilling their request directly won’t meet their need. When someone asks...

This blog is going away soon! :( Check out my new site where you can read the latest and subscribe for updates!

Hello friends!

For the month of September, I have picked a product learning focus. Normally I just read through whatever looks interesting or is available; for now, I wanted a focus so I could bolster a weak area of my skill set: accessibility and inclusion.

Part of this was spurred by the September 1 release of Building For Everyone: Expand Your Market with Design Practices from Google’s Product Inclusion Team by Annie Jean-Baptiste. Myself and some of my product / engineering fellows at RE/MAX got really excited when we saw this coming out, and decided to read through and discuss together.

And with that intro, I want to spend every Friday this month summing up the biggest points I learned during the week!

1. Don’t get so obsessed with standards that your forget about...

This blog is going away soon! :( Check out my new site where you can read the latest and subscribe for updates!

I’ve been lucky enough to kill a few internal platform products that were seen as “business critical” (but in reality, caused more heartache than value). The challenges are usually not building a replacement, instead, it’s all about communication, understanding fears and concerns, and ultimately, building each other up to a common cause (helping your customers).

Here are some of the lessons I’ve learned:

• Understanding people’s domain view / language
  • People often cling to these platforms because they have an over-estimated view of what the platform does
  • You must listen, understand, and empathize with what they think the platform does, not what it actually does (you might be surprised at the gap!)
  • Sometimes people also cling to what they think a platform might do in the...

This blog is going away soon! :( Check out my new site where you can read the latest and subscribe for updates!

A few weeks ago, I wrote about my first successful product. Now it’s time to talk about the product that came before that - the one that failed!

Note: I worked with a bunch of awesome people on this product, and this article isn’t intended as a reflection on any of those folks - just things I’ve learned about my own process, and how I should approach building products.

The failed product came before the successful one (as is usually the case). It also came afterward. I attempted to use lessons from the successful product to build a better V2, using better engineering and UI/UX. Those were good lessons to apply, but they were the wrong lessons.

Scope creep is a real thing

It started as a simple data tool that, on the surface, wasn’t even intended to have a UI. But as I...

This blog is going away soon! :( Check out my new site where you can read the latest and subscribe for updates!

Today, I get the fun job of facilitating our regular Engineering/Product retrospective. Whenever this falls on me, there are some things I like to reflect on beforehand:

• The facilitator should never be the main speaker
  • My role is to get others speaking openly and honestly
  • Taking over the conversation can sometimes stifle whether or not people feel free to contribute
• While you want others to be talking, you don’t always want the same people talking
  • Look for people who are trying to get a word in, and make space for them
  • In COVID times, this is why it’s important for everyone to have their video on!
• Some people just aren’t comfortable talking in group settings
  • Try to offer them opportunities, but don’t force it
  • Consider following-up afterward to see if there was...

This blog is going away soon! :( Check out my new site where you can read the latest and subscribe for updates!

I launched my first successful product about 6 years ago. It was an internal tool that gathered data from internal and external sources, munged it together, ran deduplication, cleanup, and formatting, and spit out an Excel file, which would then be used by the consumer team.

While building it, I pulled triple-duty: data analyst (exploring all the data pieces that had to fit together), engineer (building the thing), and product manager (taking a list of asks and figuring out what the solution would look like).

It was a mess.

• The database DDL was defined by hand, and resembled spaghetti
• Most of the heavy lifting was done by a few really big PL/SQL procs
• To make it better, some data loading was done nightly via a few random Python scripts
• UI was an eyesore - mostly sticking...

This blog is going away soon! :( Check out my new site where you can read the latest and subscribe for updates!

During quarantine, I stumbled on a great YouTube channel: that of Patrick (H) Willems, a film maker and enthusiast. I got hooked with the first video that popped up (suggested by the magic recommendation algorithm), How to Make a Perfect Action Scene. If you haven’t seen this video yet, I highly recommend it - go watch it right now!

Finished? Cool.

Why bring this up in the context of tech products? Well, I’ve seen a lot of articles in the last year on the role of storytelling in product management and software engineering. It really makes me proud. (Seriously, LinkedIn kept nagging me to change my header from “Technology Storyteller” to my current job title). But a lot of the way I see storytelling applied still leaves me a bit confused.

When I saw this video on the...

This blog is going away soon! :( Check out my new site where you can read the latest and subscribe for updates!

Last year’s Rails 6 release included a lot of exciting features, but I was particularly amped about native multiple database support! It’s really good timing - here at First.io, we’re busy scaling up to support the RE/MAX family of real estate agents.

In the long-run, we’ll need to consider more drastic measures, such as sharded multi-region database deployments. Our initial rollout will not be huge, so we have the luxury of using more laid-back scaling techniques. A good start is making sure that read-only operations use our database replica, and write-operations use the primary database; effectively splitting the load between two DB instances.

This article steps through how we ensure GraphQL queries are routed to our database replica.

Setting up an RDS Read-Replica

...

This blog is going away soon! :( Check out my new site where you can read the latest and subscribe for updates!

I’ve spent a lot of time lately thinking about data apps - which apps are successful in their goals (presenting the user with data and getting them to take action), and the UX patterns that drive that success. The Data-User Experience (DUX) Matrix was my initial take on the two factors influencing success (transparency and friction). Now let’s spend time making that theory feel real by tying it to actual examples.

In my career, I’ve had the privilege of working on lots of internal data apps. These were all bold efforts to leverage the power of data to move the needle. (Yes, that was intended to sound like a string of buzzwords :) ). Some of these apps had an impact, but most didn’t. Here are examples of two apps I was involved with that were trying to solve very similar...