#ship30for30 — @typeoneerror

essay-01.md

(1) First Day on Duty

Today is for firsts

My first #ship30for30 essay. It's also my first day on "duty" as an alternate lieutenant at the Halfmoon Bay Volunteer Fire Department. I'll spend the week on-call 24/7—ready for response—emergency and non-emergency.

I started the morning helping EMS with a stage 4 cancer patient. Car 1 (my duty designation and truck) is parked in the driveway, prepared to respond when I receive a page.

And, to be perfectly honest, today I feel more prepared to lead an interior attack on a burning structure than to write a 250 word essay. But then, I didn't get to where I am as a volunteer firefighter by avoiding scary unknowns.

I started as a recruit. I've committed to 100s of training hours, battled wildfires, and helped with medical rescues. Today I remind myself: you were a recruit back then, fresh faced and terrified (I'm still intimidated by some of the rescues we do on the regular, to be honest).

Gotta start somewhere. And this probably wouldn't be worth doing if it didn't scare me a little bit.

So here I am—reporting for duty—this time a lowly seaman recruit.

Defining success for these 30 days

I’m using this time to explore the intersections of my interests. Deeper meaning. Integration.

Firefighting has become so important to me, and there are so many opportunities and interesting problems to solve with technology in the space.

Follow along for insights into firefighting, my meandering path from fine arts to programming to firefighting, and the path of discovery that (I hope) will link these interests.

Also, a boatload of nautical puns. Welcome aboard.

essay-02.md

(2) The (MRR) Cake is a Lie

I'm going to tell you an "open" secret I heard about Silicon Valley:

Even the biggest SaaS companies in San Fransisco make the majority of their revenues doing consulting on integrations with their SaaS.

You know that "Enterprise" column on the /pricing page? That part.

A SaaS's MRR is the golden metric. MRR = Monthly Recurring Revenue. It's the "guaranteed" amount that your SaaS is generating via subscriptions every month, and it's one of the primary metrics used to judge a SaaS's financial viability.

Here's another "secret":

At its height, our SaaS Doki only brought in ~$3K MRR.

12 x $3K = $36K a year. Not great if that's all our revenue. So how did we diversity our business so we're not just a SaaS?

I booked demos of the Doki software, walking potential customers through the features and answering any questions, looking to be as useful as possible. The goal isn't really to get them to sign up for a trial; the trial is secondary to being Helpful As Fuck™.

Example: I did a demo for a designer. By the end of the demo he exclaimed "this is exactly what we need!” I also gave him some links to plugins he might use and some insights on hosting/building it should he not sign up. Remember, HAF.

A few weeks later, the designer's client booked her own demo. She was not technically savvy, but our conversation was mostly not about software. She was clearly flustered with understanding how in-person services translate online. While our software was a handy tool for distributing content online, it certainly wouldn't address her business' internal structural issues.

So I did what any smart husband would do and said "you should talk to my partner, Marie." Marie ended up booking her for a $1K roadmap project, which lead to a $15K website, and finally to a $1K/month retainer.

So if you're doing the math, we used Doki—$29/month offering—to sell $30K worth of services; the same amount Doki makes in an entire year.

I can definitely sell our company's consulting services; that's a no-brainer for me. So knowing these strengths and weaknesses, why not design a SaaS that fits your consulting operation?

Building a product can help you identify an expensive problem. A SaaS itself might not even be the solution to a potential client's problem, but it does give you a reference for talking about the problem and highlighting your experiences addressing the problem.

essay-03.md

(3) Notion Tips for Larger Teams — 1/n

Notion is a wonderful application for personal knowledge management, but—let's be honest—it doesn't shine when it comes to collaborating with larger teams. The sweet spot often feels like < 10 people, and even then, there’s a high expectation of expertise, not only of Notion, but of the systems themselves.

At Precision Nutrition ("PN"), I hold a "Documentarian" role, meaning I am accountable for building and maintaining Notion systems and standards. Here are a few key tips I've learned working with a large(r) team (around 100 employees) in Notion:

Onboard one team at a time

We started by onboarding the engineering team. We discovered what worked for them and then slowly started bringing in other stakeholders.

Starting at small scale allows you to iterate quickly and address issues at a smaller scale. Don't go hog-wild with 100 team members out the gate. It’s a recipe for sadness.

Focus on simple data types

Identify common data types your teams regularly manage. Projects are a great example, but—and this is critical—keep your data types decidedly simple.

Our Projects database at PN only has a handful of properties. Teams often create their own databases and use a Relation to "attach" it to the Projects database. An example:

Example:

• Projects
  • Shaping (Product)
  • Feature Comms (Marketing)
  • Feature Releases (QA)
  • Documentation (Engineering)

This keeps things simple and allows teams to define their own processes while also agreeing upon common processes and standards. If we put all of the properties from all of the databases above in a single database, we would have 100s of properties.

Now, you always have the option to add complexity in Notion, but I recommend you do this in a personal dashboard rather than shared databases (more on this in a future shipping container).

essay-04.md

(4) Notion Tips for Larger Teams — 2/n

Team Dashboards

At PN we have a global shared Documentation database. We create dashboards for each team and can create linked versions of the Documentation database on each team's dashboard.

Global search is still rather slow, so utilizing the search function in databases is a nice optimization.

Dashboard Templates

Complexity is best left to personal dashboards. One thing I like to do is create Dashboard Templates and store them inside a Template Button. This allows employees to quickly create their own dashboards.

For example, our Curriculum team has a "Content Reviews" database. There's also a button to create a "My Reviews" dashboard which shows all the reviews assigned to the current user and provides other helpful resources for doing the reviews.

Leverage Groups

Under Settings & Members you'll find Groups. At PN, we create groups for each team, squads, and even for feature tests (for example, when we're beta testing a new form or dashboard).

Granting access by group is much more efficient than manually sharing pages per user.

When we create team dashboards, we typically start by granting "Can comment" access to everyone and "Can edit" access to the team.

Regular Reviews

Because Notion has limited access controls, if you want to allow someone to manage content in a database, you have to give them "Can edit" access. This can be a nightmare because they can also accidentally add or delete database properties.

I recommend you set a weekly or monthly time to review top-level databases, make sure pages haven't been delete, and ensure changes haven't "broken" anything.

essay-05.md

(5) Notion Tips for Larger Teams — 3/3

Today's the last in the series on "Notion Tips for Larger Teams" (for now).

🧘 Zen and the Art of Notion Maintenance

Having many collaborators in Notion is itself a lesson in mindful practice. At absolute bare minimum, you need at least one Notion master on the team. At PN, we have 3 folks with the aptly-titled Documentarian role. Some of the accountabilities include:

• Organizing, prioritizing, standardizing, and formatting documentation.
• Being a point person for questions and inquiries related to documentation.
• Helping others write documentation and suggesting topics for roles which hold key operational knowledge.

These accountabilities were based on the work initial Notion users were doing to support the larger team. As you can see, the scope of work is non-trivial.

Some companies are now hiring to manage Notion ops specifically! Mayhap your team needs one of these.

☎️ Office Hours

Inherit a role like the above and get ready for the "I have a quick Notion question..." messages to roll in.

Via our public calendars I'd get meeting requests for Notion help, often involving repeating similar trainings. These days I make a point of only offering live support in office hours or pre-recorded sessions.

Establish clear boundaries if you inherit a Documentarian-style role. Notion's XP can be entirely different for each user—its blessing and curse—so the challenges are legion. Don't solve for one person.

📹 Looms over Litany

Use a screen-recording software like Loom.com to document your systems instead of writing in-Notion docs. It's 100x faster to visually show how things work in Notion than to describe in writing, and videos tend to make the docs stickier for your learners.

essay-06.md

(6) A Better Way To Share Finances

My approach to shared household finances has changed dramatically over the years. Here's a progression of approaches, and what’s working now:

👉 Level 1: Separated Income

Totally separate checking accounts. Personal income is deposited in your account and you contribute 50% of expenses. Unfortunately, if one out-earns the other, this often leaves one partner feeling broke and limits their ability to participate in financial decision-making.

👉 Level 2: Weighted Income

Each partner commits a percentage of income to shared accounts. Example: Partner A makes $100K, Partner B $50K. Therefore, A contributes 67% and B 33%. The lower earning partner isn't punished when it comes to discretionary income.

Salaries are inadequate indicators of actual contribution, especially when one partner provides additional emotional labour or child-care, and in a post-gender society, weighted contribution is closer to equitable.

@mariepoulin and I started here, but divided expenses to facilitate “easier” bill payments. One handled groceries, internet, house insurance; the other handled mortgage and auto maintenance. But this didn't account for ongoing fluctuations and the back-and-forth "you owe me" was annoying to track and didn't feel great.

👉 Enter Level 3: Integrated Income

We're a partnership. Should it matter who earns more? In fact, for over a decade we've often traded the "breadwinner" title.

Once I took on a FT job—a salary boost—we restructured so as to pay both salaries into the same shared account and paid for (nearly) everything out of it.

We agreed on identical post-tax salaries, amounts to allocate to savings and investments, and the exact same discretionary money.

If you earn more than your partner, does this sound unfair? I was hesitant at first, but it’s been quite freeing to not to worry about spending when basics are covered. We can now do what @shanleesimmons calls “spending to zero” in our personal accounts, because that money isn't earmarked for saving and spending.

More savings? Crypto? Games? Clothes? You can do what you want. More freedom through improved equity among peers and shared decision-making.

essay-07.md

(7) On The Clock

A tweet a while back by coder @kwyntastic got my gears turning...

I hope this doesn't get me fired but I honestly only have about 6 productive hours in me per day... is that just me?

It's definitely not just @kwyntastic; studies show the average worker is actually productive for slightly less than three hours a day. Six hours is crushing it!

Especially when it comes to programming, folks often believe the productive part of the work is only when you're heads-down in an IDE writing code. The reality is that the "lines of code written" metric is a poor indicator of value.

I'm paid based on what I've learned and experienced over 15+ years creating technical solutions. My value isn't "writing code"; it's in all the stuff I do that leads to:

• writing less, more useful code
• saving companies time and resources

At work, leaders speak on the importance of the three R's: Rest, Relax, and Recover. An empathetic employer understands that your best work isn't done when the tank is empty.

So I feel no guilt for taking my time on company time to make sure that I'm in the best shape to give my best effort. With that in mind, here are a few of the things I do on the clock to ensure best outcomes:

• 😴 Nap (to restore cognitive function)
• 🚶‍♀️ Walk (to process strategic thinking, solutions, feedback)
• 🍐 Pairing meetings (to unblock co-workers)
• 🍱 Snacks (energy)
• 💪 Skipping stand-up to lift weights (hell yeah)
• 👨‍🚒 Respond to 911 calls (volunteering makes me feel great)

Focus on impact rather than “being productive”. If you’re literally writing code 8 hours in a day, you might be burning out, and you’re definitely not operating at your peak.

essay-08.md

Rise Of The Full Stack Creator

I regularly see posts on Twitter talking about how to become a "Full Stack Developer", followed by a list of programming languages and technologies you need to learn.

These posts predictably have click-baity titles like "Top Technologies for Full Stack Developers in 2021" (don't forget to smash that like button).

Developers of all skill levels spend non-trivial amounts of time concerning themselves over which frameworks they should use. Which has the most support? Are there enough jobs for me to get gigs with this software? And the perennial "but does it scale?"

The Dev Stack

If we think of everything we need to know to develop an application, a lot of folks see the stack as something like:

• Frontend
• Backend
• Database
• Tooling

Some developers take a horizontal slice of said stack and focus on just Frontend or Backend. Full Stack Developers take a vertical slice of the stack, cutting across all layers, learning a bit of each. This makes them valuable assets as generalists. Full Stack Developers remain in high demand.

Want to be even more valuable?

Consider that the entire Development stack is a horizontal slice of an even larger stack.

This stack has layers like:

• Research
• Customer Care
• Accessibility
• UX
• Design
• Development

Development is a tiny layer of the stack you'll need to take a vertical slice of to create, market, sell, and support a product.

The future of product development lies in taking a vertical slice of this larger "Product Stack". A stronger understanding of the layers in this stack will make your role in Development better informed, more valuable, and more impactful.

Become a Full Stack Creator.

essay-09.md

(9) Are You Fire Ready?

As I sit to write today, I am physically and mentally exhausted. I just returned from seven hours knocking down a small wildfire in the outskirts of our district.

After extinguishing and overhauling three rekindled slash piles, we returned to our hall. You might imagine everyone would want to go home at that point, but, nope, we had to spend another hour cleaning and relaying hose, resupplying the trucks with water, and even washing the trucks (firefighters ❤️ shiny trucks).

This is all to get our apparatus "fire ready".

When responding, even a single out of place piece of equipment or anything amiss on an apparatus is enough to delay a response. Even seconds can be key when responding to a structure fire or a medical incident like a cardiac arrest.

Most jobs are not as critical as an emergency response, however, leaving your workspace in a "work ready" state when you shut down for the day is critical to how you respond the next time you return to work (you do shut down at some point, right? 😅).

My process includes separate startup and shutdown routines written in my journals in Notion and Obsidian (where I use "Templates" to quickly create a punchlist).

My shutdown routine includes:

• Process email and remaining to-dos (GTD-style)
• Planning the next day (Prep journals, time-blocking, punchlists)
• Making sure I review tomorrow's meetings so I don't forget something (I need multiple reminders in Calendar, Notion, et al)
• Quitting distracting apps (Slack, Email, Twitter, et al)

The last one is critical for me. If I leave email or Slack open, I'll immediately jump into work the next morning when I reach my desk, skipping crucial prep work like journaling, reviews, and day-planning.

What do your routines look like?

**Are you "fire" ready? **

essay-10.md

(10) "Disrupting" the Fire Software Industry

With wildfires in the news again, I'm reminded of a past summer when I spent a week in the BC interior fighting wildfires at the Burns Lake complex.

(I know, I know...Burns Lake 😜)

Besides the grueling 15-hour night shifts, one thing that stands out in my mind was an interaction I had with our Task Force Leader. He showed me an iPad running an app for performing Incident Action Planning, and, as he gave me a demo, excitedly exclaimed, "it's not software; it's an app!"

What he meant by this is that it was an app he could install and use on any device and receive updates at will, differentiating it from desktop software.

The firefighting industry's software landscape is quite dated; a great number of the tools available still only run on desktop machines (and often only Windows desktops). Installing software such as RMS (Record Management Software) often requires techs to visit your fire hall and manually install software. When something goes wrong or the software needs patching—you guessed it—another tech visit.

I've been making apps for years, so I thought it pretty amusing how stoked he was about over-the-wire updates, but it got me thinking about what kind of opportunities exist to make modern apps for firefighting.

I could try to make the next whiz-bang, augmented-reality training software, but I could also stick with the known, and make a kick-ass RMS for Canadian fire departments, one that works flawlessly on mobile and isn't Windows-only.

Point being: you don't have to invent something brand new to get traction in an industry; even how the product is delivered can be revolutionary.

Market beats functionality every time.

essay-11.md

(11) The Retention Problem In Online Learning

Information retention is an important metric in educational design, one that often gets ignored in online courses in favor of basic completion stats.

Consider: how much of the information you present is being retained by your learners and how are you evaluating this?

Many infopreneurs do not design info-products with any sort of transformational learning goals in mind.

My hot take: the majority of "online courses" are repackaged blog posts with a price-tag attached. And most "cohort-based courses" are the same—with a Slack attached. 🌶

In learning design fundamentals, there exists the concept of the "learning pyramid":

The learning pyramid describes a hierarchy of teaching formats and how much information is retained at each level.

Towards the bottom of the pyramid is Reading. Learners can be expected to retain ~10% of information they read. That's only marginally better than the ~5% they retain from Listening to a lecture.

Further up the pyramid, we see a substantial rise in retention with Group Discussions at ~50%. Now we're into our Slack communities, but my guess is actual group discussion means something closer to what you might call "breakout rooms" in Zoom than a forum or Slack group.

At the top of the pyramid, we have Practice and Teaching (where the student is teaching what they've learned), which weigh in at an impressive 75% and 90% retention, respectively.

It quickly becomes clear that a bundle of readings are not going to help learners retain much information. Can we call them learners at 5-10% retention, or are they merely consumers?

In order to facilitate transformational online courses, consider which tools you might use to provide practice, simulation, field experience, role-play, and other immersive experiences—the types of experiential activities that enhance learning outcomes and information retention.

essay-12.md

(12) My Firefighter Origin Story 👨‍🚒

Marie and I had visited Sunshine Coast, BC one summer for a retreat, and when we started thinking about buying a house, realizing we couldn't afford a place in Van, we decided to check out the Sunshine Coast again.

We stayed with an online friend of Marie's while we spent two days looking at houses all over the Coast. On the second day, we saw a cute rancher in Halfmoon Bay and immediately knew it was the one. 😍

The place looked straight out of 1978, but had solid bones, and a cool open-format layout. Marie's friend thought we were a bit strange buying a property in a place we'd only visited during the winter, but we excitedly put in our offer.

Three months later, we moved from Vancouver to our new home; a vacation town of about 1,500 in the winter and double that in the summer.

That evening, with no internet and a foot of snow on the ground, we traipsed over to our new friend's house. She was throwing a birthday party for her partner who happened to be a local firefighter.

I recall being "cornered" by a few other firefighters, one proclaiming "See you at practice on Wednesday, 7pm." I think I awkwardly blurted something like "Uh, hah, yeah...I'll think about it." 😅

Over the next week, I did think about it, and, realizing I was now living in a town with no shows, no restaurants, and pretty much fuck-all to do in the winter, I drove over to HBVFD's Hall 1.

That night I cut a door off a car with Holmatro cutters, affectionately called the "Jaws of Life".

Burning stuff, chopping up cars, and otherwise hanging out?

I was hooked from the first minute. 🔥

essay-13.md

(13) The Benefits of Volunteering

As I get older, more meaning is driven by striving for self-improvement, and beyond that, living to help others. Becoming a volunteer (firefighter) has given me some incredible benefits. Here are a handful:

Developing empathy

Caring for folks at their most vulnerable has taught me that most people are struggling. I've seen so many issues that I hadn't previously considered. It's been said: you don't know what's going on in most peoples' lives, so treat everyone with kindness.

Duty & discipline

Because we're always responding, 24/7, I have to respond ASAP on short notice. This has lead me to develop routines that allow me to act quickly and decisively. I feel more in control, and I've developed a stronger sense of action in my life. I feel myself having less internal push-back when faced with difficult moments.

Education

Most of our training is provided for free. Beyond firefighting, I've taken courses in:

• Instructional design
• Command & leadership
• Incident management
• Hazmat operations

A lot of these free trainings have been super helpful in other areas of my life.

Expanding your peer groups

Prior to volunteering, most of my friend circles were around my age +/- five years. One of the hugest benefits of volunteering is getting to collaborate with and get to know folks of all ages. There is a wealth of interesting experiential knowledge accessible to you as a volunteer.

Helping feels great

How many superhero movies must one watch, to compensate for the atrophied expression of one’s greatness?" — Charles Eisenstein

Neuroscience has shown the when you help someone, you get a bump of oxytocin. **Saving lives and property makes you feel like a superhero. **

You too, reader, are great, and you can share that greatness. Volunteer!

essay-14.md

(14) Product idea: FireCommunity.ca

Firefighting is largely about managing resources. In all-volunteer departments, resources are acutely limited, especially when in comes to digital technologies. Sure, there are many physical gadgets we get to play with, but day-to-day, members are often using paper books and Facebook to keep records and stay updated.

Thankfully, I convinced our members to start using Slack. We also use Notion to manage our training and roster. This is pretty much the extent of the modern digital services we use (apart from the ancient database software we have to use for record management).

I had set out with a plan to create a website template for all the small local departments. The plan: a WordPress template with a shared banner that matched the website of the AHJ (the "Authority Having Jurisdiction").

The Sunshine Coast has a number of different fire departments, each with different needs and members, but they all need a way to publish information. Most of the websites are out-of-date and not modern.

As 2021 crept around, I didn't carve out the time to build the template, so the departments looked to web consultants to build their websites.

I started to think that what we could use is a place to publish information about our department(s) that handles the basics of what a public site needs, and is separate from something as awful as Facebook.

Now I'm considering building a simple department directory and launching at it firecommunity.ca. This'll be a simple way for all Canadian fire departments to be included in a searchable index and use their "profile" as their website if it suits them. I might even use Notion to build it.

I'll use this micro "product" as a research portal for some larger ideas I have for the fire service.

essay-15.md

(15) Everything I Learned on Doki.io (0/n)

Earlier this year, I made the decision to shut down doki.io, our online course platform.

After 5 years, it was a difficult decision, especially given than it is still profitable, and—at this point—requires little support. However, the cognitive overhead ended up being too much with a full-time job and a boatload of new ideas (especially in the firefighting technology space) I want to explore.

At one point in 2020, we had an offer on the table to purchase doki.io from us, and profitable operating SaaSes are quite the hot commodity these days. However, the anxiety of doing a bunch of work to transfer ownership to a new party, and the fear of it becoming "something else entirely", however irrational, became the loudest voice in my head. So I decided to sunset instead of sell.

Today I am feeling like shit, recovering from my second Moderna shot. Starting tomorrow, I'm going to write a week's worth of lessons I've learned building a B2B2C software-as-as-service.

Some of the topics I'm considering exploring include:

• Don't build for yourself
• Don't build for one customer
• Don't target multiple markets
• Launch early, launch often
• Buy versus build
• Customers care about your longevity
• You don't need to be "always on"

Thinking about launching your own software project? Have any questions for me?

Feel free to AMA and I'll address it over the next week.

essay-16.md

(16) Don't Ship To Crickets: Use JTBD

Using Jobs To Be Done theory will help you launch successful products.

A Job to be Done is the process a consumer goes through whenever she aims to transform her existing life-situation into a preferred one, but cannot because there are constraints that stop her.

I wish Alan Klement's When Coffee and Kale Compete had been around when Marie and I started working on Doki.

In 2014, we white-boarded, sticky-noted, and authored a massive list of features that Marie wanted. We asked ourselves: what are the most important things to focus on?

Then we just started...building.

I worked sporadically for months and eventually determined we'd never ship without devoting unimpeded focus, so I spent a quarter building the MVP and launched to a handful of customers (mostly friends).

Those customers were the first people to see the product.

Big mistake.

• Friends told us what we wanted to hear.
• Customers told us what they had expected it to do.

We'd heard none of it because we talked to them after launching.

The struggle to gain traction early was a result of building to suit Marie's needs instead of potential customer needs.

Alan, again:

Customers don’t want your product or what it does; they want help making themselves better (i.e., they want to transform a life-situation, make progress).

We build what we thought creators wanted based on what we wanted. Turns out the audience who needs course platforms was (surprisingly) nothing like us.

Don't be surprised when you launch.

Ship products that immediately allow customers to make progress.

We would've had more success if we had spent 3/6 of those first months interviewing customers and determining what "job(s)" course creators needed to "hire" Doki for.

essay-17.md

(17) Start With One Target Market

If you're building your first software-as-a-service (SaaS), stick to one target market.

Typically, B2B (Business-to-Business) is easier to start with than B2C (Business-to-Consumer). Whatever you do for your first SaaS, pick one of those two options.

**We didn't, and made it feel like we started our first software product on "hard mode". ** Doki.io could be considered B2B2C software. In "normal" B2B software, you are selling a product to a business that uses the software to solve a business need. Adding the 2C in this case means that our customers use Doki to create and sell products to their customers, making Doki what is sometimes referred to as a multi-sided marketplace (MSM) or platform.

Unless you're a masochist, I highly recommend NOT building an MSM for your first outing into SaaS.

The problem with an MSM structure is now have two types of customers: your customer (what we call "Tenants") and your customers' customers (what we call "Students").

In our application:

• Tenants are looking to create, package, and deliver their courses.
• Students are looking to purchase and take courses.

These are orthogonal concerns, and require their own research, user-experience, and marketing strategies (not to mention double the programming or more).

If you're starting as a small team, it can be challenging to target more than one market without dedicated research, product, and support staff. If it's just you...forget about it.

(But I really want to...)

Okay, so your grand idea is to target businesses and also consumers with some sort of marketplace. My recommendation is-if you're serious—start with substantial research on both sides of the marketplace, and think about how you can ship the smallest slice of each first.

Also: good luck. 😅

essay-18.md

(18) The Halfmoon Bay Creek Fire

At around 16:30, Halfmoon Bay Fire Department received a emergency dispatch of a wildfire near some powerlines. Reports of gunshots in the area. I radioed dispatch that we would meet RCMP down the street and let them investigate before we proceeded.

Sadly, it become quickly clear there was a major wildland fire in the area, and it'd be unlikely that folks shooting guns would stick around, so we proceeded to the scene.

Seemed like about a half hectare on fire upon arrival. We staged apparatus and started getting water on two flanks of the fire with Pumper 1 and Tanker 1, performing a "pincer" attack.

Unfortunately the fire was already about 100 meters into the brush, and, with no way to attack from a road, forestry was called in to assist.

Two forestry helis bucketed the fire while we protected the flanks. We extended our hoselines towards the head of the fire and were able to surround the area. We then performed overhaul work, which is protecting our lines of attack and working inwards, using shovels, rakes, and pick-axes to build firelines and extinguish burning detritus. Tanker 1 shuttled water to Pumper 1 which pumped water to two forestry lines ( with a wajax pump supporting).

The crew was on scene until about 22:00, and then a firewatch team began assisting forestry with containing and patrolling the area.

I was just about to head out to lift weights before the call. Didn't need a workout after that.

Going to be a rough summer in the Pacific Northwest, folks.

Please think about your evacuation procedures and have go-bags ready if you live in a wildland urban interface area!

essay-19.md

(19) Don't Build For One Customer

In previous essays, I discussed two things to avoid when creating your first SaaS:

• Don't build for yourself (use Jobs-to-be-Done)
• Don't target multiple markets

Early on in my essays, I also mentioned leveraging your SaaS to offer consulting via your software. However, there's one more thing you should be careful of with consulting-as-a-service:

Don't build features for one customer.

Especially not for free.

If one customer requests a feature or tells you they "need" a feature, you don't have to build it.

We did this a few times with Doki. One example was a feature that took me a full month to build. It was pretty sweet, and I thought I be able to leverage it to attract other customers, but only 2 customers ended up utilizing it in any way.

I did not offer to build a custom "enterprise" solution for the customer under a paid consulting agreement. I just said "sure, I can build that", thinking it would be a great feature.

A full month of work for a $29/month subscription fee. Doesn't make sense.

As they say, "no is a complete sentence."

Of course, it always helps to give customers some hope. Perhaps an email template that lets the customer know you've heard them.

Here's an example from Notion:

Thanks for reaching out! We don't currently have a feature that allows you to X. A few other users have reached out about X.

I’ll pass it to the product team as well to help prioritize it 👍

Use Jobs-to-be-Done to determine new features meet a customer need and helps them progress. Otherwise your customers will just say "that's nice."

essay-20.md

(20) Always-On Services

If you're a consultant, two reasons you might be thinking of launching a SaaS:

• Great way to create passive income!
• I hate having clients!

💸 Passive Income!

When we first built Doki, one of our loose goals was replacing my consulting income with product revenue.

Reality: there's nothing "passive" about being a solo-founder running a SaaS.

A SaaS is not a set-it-and-forget-it product!

Upgrading, documentation, support, selling, marketing, demos...wait...when do I have time for those new features again?

🙅‍♂️ No More Clients!

"You know, it'd sure be easier to just build a product and not have any clients." -- You, a rube, presumably

The bad news

Your site will go down. Your database will disconnect. This'll happen any time of day. Customers expect 24/7 up-time; apps don't stop needing support when you're asleep.

Instead of a few clients that you know really well, now you have 100 that kinda don't care about you personally.

The good news

Most websites are barely "three 9s", aka 99.9% uptime (don't expect yours to be better), and so things being slow, down, or broken is a more common experience than you might realize.

Customers often solve their own problems

"Weird, it works now."

Majority of support is one issue

"I can't log in."

Literally. Spend a lot of time making your login page bulletproof. Be overly pedantic writing docs for how to reset your password.

RE: "people not caring":

Humanize support emails. Customers may start upset, but help them solve a problem (even outside the scope of your product) and most folks respond favorably. Finding our there's person on the other side (and not an automated recommendation of forum posts) softens even the toughest customers.

essay-21.md

(21) Communicating Nonviolently

When I started at PN, my boss recommended Nonviolent Communication ("NVC"), a book and methodology developed by clinical psychologist Marshall B. Rosenberg.

Wikipedia refers to NVC as "a method designed to increase empathy and improve the quality of life of those who utilize the method and the people around them".

Being used to working solo, my first months at PN I was "stepping on toes." I saw opportunity for improvement and acted. Unfortunately, sometimes the systems I waltzed into were another's accountabilities. Perhaps intent was admirable, but the delivery was flawed. I was communicating "violently".

Believing we have to “fix” situations and make others feel better prevents us from being present.

People in need often want a listener, not a fixer. I habitually jump to solutioning. If you want to resolve a tension, opt for listening over action. When people feel heard, they'll ask you what you think.

Defer solutions until the need has been adequately identified.

Another book Crucial Conversations speaks of a "shared pool of meaning". The flow of meaning into the pool necessarily includes all parties.

Dialogue calls for the free flow of meaning...

The goal in conversation is to contribute to the pool and focus on the needs of the participants. If you only consider your needs, it's unlikely you'll convince others to "see it your way". If a party feels unsure of your intent, safety is compromised and communication breaks down.

As people begin to feel unsafe, they...move either to silence (withholding meaning from the pool) or to violence (forcing meaning in the pool).

Seek to understand rather than to judge or evaluate—ask what the other person needs in relationship—and people become more open to your ideas.

Work on developing shared understanding rather than being right.

essay-22.md

(22) Dare To Share Your Ideas Publicly

I saw a tweet recently that has ~9,000 likes and many responses agreeing with its premise:

Keep your ideas off of here...Never underestimate someone who may not generate the idea but has the means to execute on it.

I couldn't disagree more.

Web commerce moves way too fast and there are too many people creating products these days to "Field of Dreams" it in secret in 2021.

As an application developer, I go through this on the regular with friends, neighbors, and other random folks that discover I make apps.

"I've got this idea, it'll make tons of money. Sign this NDA so I can tell you about it!"

Nah, I won't sign your NDA. I am certain the idea's been or being executed already, is making multiple companies money, and isn't all that novel.

Execution is important, but the validation that your execution hits is more important.

You've got the idea. Is it a good idea? Even if it is, are you the person who can make it a viable product? Can you get randos to part with their dollars, convinced you're the best person to implement the idea?

Take it from me. I built a platform for launching courses that started around the same time as Thinkific's online course platform. One off us is shutting down our platform and the other just IPO'd on the NYSE 😅. What's more valuable? The idea "build an online course platform" or the team, the strategy, and the effort that goes into positioning that product?

So, fuck it! Throw caution to the wind! Publish your ideas. If someone "steals" your idea and has success with it and you don’t, then the idea itself wasn't what was valuable, now, was it?

essay-23.md

(23) Worried About Churn? Focus On Your TTFV

Ever bought a software subscription before you were ready to use it?

Of course you have!

You set that $29/month ablaze for a year or so and then realized:

"Turns out <insert excuse here>; I'm not using this software at all".

Doesn't matter what the excuse was (zero judgment), but why do we buy before we're ready?

---

Churn is a word in SaaS terminology describing when customers cancel their subscription.

The biggest reason our customers churned was because they weren't ready to make an online course. The realization "software doesn't actually write content" is a tough one.

Early on we recognized that Doki's "North Star" metric was TTFS, or Time To First Sale, e.g. how long does it take from when a customer signs up to their first course sale.

Because creating an online course is W-O-R-K, we optimized onboarding and training to optimize for TTFS. We even produced a course of our own—Run Your Learning Launch—that taught how to sell early-stage products (and not to worry about perfection).

We wanted customers to succeed with our platform, which often meant them having sold courses previously. Chances were good: if Doki was your first time shipping an online course, you'd churn.

With this in mind, if you are creating a SaaS, it's important to consider: what is the TTFV, or Time To First Value of your platform (for us the Value was "Sale")?

How quickly can you produce success (value) for your customers?

Beware long TTFVs. These are churn indicators!

Other considerations:

• What does the customer need to learn to use your platform?
• Is customer's continued use of the platform linked to how much they earn?
• Could you niche down product to minimize TTFV variance?

essay-24.md

(24) I Have Doubts

Motivation is sparse—one of those days where incentives like "better analytics" and "grow your audience" hold little appeal.

One of those days where I have absolutely no interest in writing an atomic essay. A chore—the dishes are more alluring.

Why did I pursue this challenge?

Did it start as inanely as "Marie is doing it, could be fun?"

How high was I thinking this would be fun?

Am I trying to grow my audience?

Reader, I don't know.

I intended to explore the intersections between my experiences with firefighting and software, but I really haven't done that, have I? Besides, who on Twitter is buying firefighter software (@ me, you cowards!)? Or even reading about it? Is this really the right use of my time (or target audience) if I want to research this intersection?

Perhaps I should just write? Work on the habit. Forget intention. There's value to just learning systems for writing, right?

Speaking of value, tell me, reader: have my posts been useful or enjoyable? Are you just here to cheer (nice, thanks!)

It feels like the only folks interacting with these post are in #Ship30for30 (is this true, or selection bias?).

At some points, I've mostly been wondering if I'm annoying any non-Ship30for30 followers with these image-only posts.

Did any of them mute #Ship30for30?

In any case, it's great to know what the process looks like for designing a content-creation system that works.

I've never been so prolific.

I'm also looking forward to this being finished.

essay-25.md

(25) The Best Keyboard Ever 🖤

You may regret asking me for keyboard recommendations.

I own a custom-built Ergodox EZ, Advantage2, and currently main ZSA's Moonlander.

If that sound like a cyberpunk novel to you, that's okay—I gotchu...

The Case for a $365 Keyboard 😅

I have chronic RSI, which lead me to be keenly aware how much input devices matter.

Folks spend thousands on computers, and invest 100s of hours learning productivity tools, all while sticking with the default Apple keyboard.

You use your keyboard daily, perhaps more than any other device. A better-suited ergonomic keyboard will improve not only productivity, but health outcomes as well.

The Keyboard ⌨️

I've spent a lot of time playing with mechanical keyboards and the Moonlander is the best, hands-down. Beautiful, colorful, and obscenely customizable (to the level where I rarely use my mouse).

Configuration ⚙️

You can modify how Moonlander operates by using Oryx (ZSA's configuration tool) and Wally (app for saving settings to your board).

I configured keys that perform multiple keystrokes at the same time. Some examples:

• One-key window moves with Mizage's Divvy app
• Emoji/screenshot/Alfred buttons
• Hot-key for "Paste without style" (macOS users know this one!)

Layers 🥞

You can add "layers" with Oryx. Layers for different typing layouts like COLEMAK, DVORAK, et al. Layers for music, programs-specific actions, and more.

Switches 🎛

• Cherry MX Browns/Reds are great all-around switches.
• Blues are your classic clackity-clack. If you hate your co-workers, these are fantastic.

Pick up a keyswitch tester. That's how I landed on my personal favs, Kailh Coppers.

The Challenge 😓

"Columnar" layout (keys aligned in columns rather than rows) feel weird at first. Folks typically suffer a few weeks of abject misery, then typing is 2x faster with half the pain.

The gains are worth it, I promise!

essay-26.md

(26) New Computer? Create an INSTALL.md!

Setting up a computer for development can be a huge PITA, but it doesn't have to be.

Developer @zinyando remarked on Twitter:

Setting up a new machine is always a pain. I don't remember half the tools and packages that made my life easier. My terminal sucks right now 😢 😢

I get it.

I've used a laptop for years, accumulating aliases, shell scripts, programs. Then on a new machine, you have to start all over again, copying and pasting as you go.

There's a better way.

Enter INSTALL.md.

On Dropbox, I curate an INSTALL.md file with instructions detailing setting up a new machine.

Here's part of my instructions (markdown):

* Install macOS updates.
* Install Xcode from App Store for git/tools.
* Open Xcode, accept license, finish installing components.
* Enable FileVault/Firewall.
* [Generate SSH keys](https://help.github.com/articles/generating-an-ssh-key/) for Github, et al.

        $ ssh-keygen -t rsa -b 4096 -C "ben@weareokidoki.com"
        $ eval "$(ssh-agent -s)"
        $ ssh-add ~/.ssh/id_rsa
				
* Add keys to Github, et al.
* Clone and config [dotfiles](https://github.com/typeoneerror/dotfiles)

The dotfiles step is notable. Many devs keep configuration files in a repository on GitHub. This allows them to quickly get a pre-configured terminal environment running pretty much anywhere.

My daily driver is a Macbook Pro, but I connect to a Ubuntu Server-based NUC for development. The dotfiles repo means setup is as simple as: install Ubuntu, clone dotfiles, run the ./link.sh script contained therein.

Instant vim setup, aliases, git config, and more!

The other thing I curate in INSTALL.md is a list of apps to install with serial numbers linked in 1Password.

Stop trying to remember how you configured a previous machine and use an INSTALL.md to document your setup. Your future self will thank you.

essay-27.md

(27) Stop Planning, Start Theming

Marie, today: "I have so many essay ideas!" Me, half-jokingly: "Can I have one?"

So today's episode around how I plan my life through Themes is brought to you by @mariepoulin

Marie seems to think I "meet all my deadlines" (highly moot) and that I'm able to manage firefighting, work, side-projects, house maintenance, etc., without dropping the ball.

To start, let's get the elephant out the room:

We don't have kids.

Phew, now that we addressed my proverbial privilege, let's tuck in...

🍱 Themes

In Notion I have a Themes database. It has 7 entries for days of the week. Each of these days has the fields:

• Theme
• Project
• Studying
• Reading
• Workout

"Theme" is one of the following: Product, Fire, Investing, Code, Personal.

Of course Project, Studying, Reading, and Workouts are links to other Notion database, where I track progress, take notes, and build study guides.

My daily Journal is linked to Themes. Via rollups, when I pick the day in my Journal, I can immediately visualize my focus for the day. Via nested rollups, I can also see "Next Actionable Step" (NAS) and "Next Minimal Step" (NMS).

• NAS is the most important task to finish on that relation, be it a firefighting course, project, or book.
• NMS is a pomodoro-scoped task I can do on that project if I don't quite have the time to devote to it that day, coined as an "OST" (One Small Thing) by my former coach María Aldrey (@kirisima).

Much like #Ship30for30, progress is about small gains, not huge projects.

At Precision Nutrition we have a of guideline around this “1% improvement” concept:

Progress, not perfection.

Use our continuums to make choices that are "just a little bit better [every day]..."

essay-28.md

(28) It's Better Together: Asking for Help

As developers, it's bizarre how often we work "together separately".

Especially in an increasingly remote-first world, shared organizational knowledge is critical.

Siloed knowledge increases your organization's overall "bus factor" and means that folks often get stuck doing work that is outside of their unique abilities (the tasks at which they excel and are passionate about), essentially because they're the only one who can do the work if it is not shared.

Asking for help is a productivity super power.

Pair programming with a mature partner or team is the Avengers Assemble of productivity.

More (and sometimes less, but better) work gets done, and the opportunities to learn are endless.

Practice asking for help to accelerate your progress.

Try asking for help when you don't need it. Why not? Folks love being seen as competent and asking them for their support goes a long way to making them feel valued.

One of the myriad benefits to asking for help when you already know what you're doing is you might be rewarded with something you didn't know. There are so many ways of approaching problems and you might be overlooking a great solution by going it alone.

Succeeding together on an arduous task is so much more rewarding that soloing.

And when you succeed together, you don't need to brag, because your partner(s) already know!

Find a friend—perhaps an acquaintance. I'm always open to pairing, but rarely do people ask. If you feel comforatble, perhaps try a service like FocusMate, which pairs you with a rando. Or ask for help on Twitter. You never know who might be available.

Let's do better. Let's ask for help and be open to helping when we're asked.

essay-29.md

(29) Formatting Notion Headers with KaTeX

Did you know you can use LaTeX (a document typesetting system) in Text fields in Notion to format Gallery and Board cards?

Notion queen @mariepoulin introduced me to the concept recently, and I spent the day after down a LaTeX rabbit hole.

Technically speaking, Notion uses KaTeX, a similar library that doesn't quite have the same support as LaTeX, but it's close enough.

Extending my Themes database I wrote about in #Ship30for30 recently, I added fields like Heading: Projects and Heading: Learning to my database.

To add a heading:

1. Click into the content area of the text field and write a word.
2. Select the word.
3. In the menu that comes up, click the Create Equation button
4. Add the following KaTeX equation:

   \footnotesize \color{FFA344} \textsf{\textbf{PROJECTS}}
   

Let's break this down and explain each part.

• \footnotesize sets the font size to a small font
• \color sets the color of the text. the content inside the {} is the "hex code" of the color. You can reference @optemized's Notion Colors guide at https://optemization.com/notion-color-guide to find the Dark and Light versions of the Notion colors so yours can match. I'm a Dark Mode fan myself.
• \textsf sets the inner content as a "sans-serif" font and textbf sets the inner content in bold.
• Finally PROJECTS is the text you want to display.

Now in gallery mode, sort the Heading fields above the content they relate to and you have a nicely designed card with headings instead of a dump of relations.

There are loads of different style and format options so check the KaTeX docs for yours!

essay-30.md

(30) Fuck This Shit, I'm Out

Ha, just kidding. Mid-program, I did have doubts about finishing #Ship30for30. I'm glad I stuck through until the end.

How have you improved as a writer and creator?

Editing skills have improved substantially. While the < 300 words rule felt arbitrary at first, I found forcing myself to be concise lead to the cutting of superfluous noise, allowing me to get to the damn point.

This is going to help with product, documentation, and copywriting efforts going forwards, especially considering most consumers' limited focus.

One note here: as a programmer, we often play code golf (how can we write fewer lines of code to get this done), but less can often be less clear. Sometimes it takes more to make work understandable. So I'm taking away that concision is important, but it's not everything.

What was the most surprising part of #Ship30for30?

I am now SUPER looking forward to writing in long-form format again, and that is unexpected.

What was the biggest lesson you learned about yourself?

I need a reason to write. Setting some intentions and having a framework is critical.

Which of your goals did you accomplish in the last 30 days?

My goal was 30 essays. Done and done.

What advice would you give or a new shipper 30 days ago?

Don't get fancy on the design of your template. Just write.

Share your Twitter growth, impressions, etc.

It was notable, but I don't care, as it's unimportant to my direction.

What's next on your writing journey?

Finish my website and design a long-form content writing system. I won't be writing daily, but I want to keep the habit going because it is truly beneficial to my product thinking.

Cheers, and thanks for reading!