Why I joined LaunchNotes

Hi there! 👋🏼

I’m Bryce, and I’ve just joined the LaunchNotes engineering team as their newest software engineer.

My joining LaunchNotes has been the culmination of several invisible forces and fortuitous experiences, and I couldn’t be more excited to dig in and begin helping to advance the mission of improving how teams everywhere communicate product change.

Why LaunchNotes?

As an empathetic engineer, I know all too well the acute pain around internal and external product communication. If I had a dollar for every time I was asked the status of a feature, or shipped a feature that ended up confusing or frustrating customers, I’d definitely still be joining this awesome team... but would have the luxury of working for LaunchNotes pro-bono.

Joking aside, the problem LaunchNotes is solving is a massive challenge for software teams everywhere, and being a part of the solution presents a genuine opportunity to improve the life of businesses large and small. And in my experience, it’s not just technology companies that are having this problem either. Managing change communication is a problem faced by every product company... and today I believe every company is becoming a product company (more on this below!).

But before I go any further talking about product, here’s a little bit more about me...

How did I get here?

During my time at UNC Chapel Hill, I stumbled into the world of startups and immediately fell in love. I was enamored with the comradery and passion emanating from small teams setting out to bend the will of the world to their view of the future. Not having a technical background, I consulted with these teams on marketing and finance and generally helped out where I could. But the more I consulted on the non-technical side of things, the more I was drawn to the creative expression and tactical constructing being done by the product teams. These college experiences planted the seed that I might one day like to get my hands dirty building software products myself.

Graduating with a finance degree, I took a slight deviation from this path to join a wealth management firm in Denver. As you could have guessed, I only stuck around for a year. While at the firm, I worked with the portfolio management team building statistical models, but deep down continued to feel the draw of the software industry, and specifically building new software products. And so I began to teach myself how to code. During the day I wrote models in R, and at night I would come home and teach myself Ruby on Rails. After only a few months of this experiment, my fate was sealed, and I knew my future wasn’t in R, but in Ruby on Rails and web application development.

In 2014 I was lucky enough to be accepted to the Turing School of Software and Design in Denver, and after seven intense months, I became a newly minted software engineer. The next several years I built tools for finance teams, tech for labor marketplaces, software for legal firms, and even business intelligence tools for a pressure washing company. These experiences not only allowed me to cut my teeth very quickly in the world of web app development, but also solidified my view that software is in fact devouring the world. Or, as I like to reframe this mantra: “every company is becoming a product company”.‍

If every company is becoming a product company, then every company needs help communicating product changes

Whether it’s your local taco truck or a Fortune 500, every company is selling a product or experience. And more often than not, software comprises a large part of how these products and experiences are created or delivered. This software makes it easier for companies and teams to iterate faster in response to customer needs and requests. And all those iterations lead to... you guessed it: product changes.

While I don’t think we will be doing focus groups with food trucks anytime soon, I do believe every forward thinking company can increase engagement from a change comms process that’s smoother, faster, and more focused than what the vast majority of the world is doing today. In fact, every company I’ve worked for has made its own attempt at roadmapping, communicating (or postulating) the status of features, and disseminating this information out to users, both internal and external. And every one of these companies has left a lot to be desired in this department. In many ways, it’s still very much the wild west when it comes to changelogs and product communication tools.

Then came LaunchNotes.

Joining the LaunchNotes team

My intro to LaunchNotes came through Matt, LaunchNotes’ Engineering Lead. Both from North Carolina and both graduates from UNC, Matt and I became fast friends in Denver. Over the years, we’ve spent a ton of time enjoying the outdoors, from mountain biking to backcountry skiing. Matt has also played an instrumental role in my development as a Software Engineer, as he had previously made his own transition from QA Analyst to Software Engineer, and understood the winding path I’d taken better than most.

I have a lot of respect for Matt, both in his talents as an engineer and manager, but also his general approach to work and the kinds of teams he enjoys working with. In short, I knew when he joined LaunchNotes it must be an incredible team. Having now been here a few weeks, I can attest to that excellence firsthand. 

Each person on the LaunchNotes team has personally felt the pain of poor product change communication, and is passionate about being part of the solution. Moreover, this is not only an incredibly talented team, but also a team that’s been around the block several times before. I couldn’t be more humbled and excited to work alongside them as we build the de facto standard tool for communicating product change.

Reach out any time

Questions about what we’re working on at LaunchNotes? Or my transition from finance to software engineering? Or skiing? Or anything else I’ve discussed above? Don’t hesitate to send me an email at bryce [at] launchnotes.io. I’d love to hear from you!