It’s important to write on your own website. It helps with building your personal brand, controlling your content, and many other things. But what’s the best way to build a website to write on?
All at once? No. Piece by piece? Closer. In increments? Bingo!
Fundamentally, this is not a big discovery. Most contemporary product development processes encourage breaking projects into smaller chunks. It makes sense to approach a personal blog the same way: Build one increment after the other.
Unfortunately, for past blogs, I always tried adding everything at once. I felt like I needed comments, tags, an RSS feed, etc. in order to start writing. All of these features are pretty simple individual tasks, but collectively they suck the joy out of writing.
My goal was to spend more time writing and less time coding.
The concept of “incrementally building a blog” gave me permission to not build anything until I stubbed my toe while writing, publishing, or reading a post.1 It empowered me to worry less about the packaging of my ideas and focus more on how I communicated them.
Practically, how does this process work? First, I write a post in Markdown, either in Roam or my text editor. Then, I add it to my local blog site and see how it “looks.” If the post renders incorrectly, I’ll add the simplest fix needed to hit “publish.”
Code snippets are a good example of a lurking stubbed toe. None of my posts contain inline code or code blocks yet. Eventually some probably will. Until they do, there’s no reason to spend time adding support for syntax highlighting or other code-related features.
Another happy side effect of building my blog in increments is it encourages me to write more. There are features I want to add (search, tagging, an archive), but don’t make sense for a blog with only a few posts. There’s no utility in pagination unless I write more posts than fit on a page.
Right now this process works well. I anticipate it will continue. It also protects me from blog envy, where I rush to add a shiny feature I see on another blog.2
I finally put a name to this idea when I saw Frank and Jonnie’s blogs. Both are redesigning their blogs publicly by documentingchanges.↩
Before this current version, I was so frustrated with my personal blog that I started using Posthaven. I was trying to write every day and Posthaven’s lack of features helped me stay focused. You can visit it at websgrain.com.↩
Something I’ve had top of mind for a while is the idea of building paid software. Not in a business-school-make-money kind of way though.
I’m interested in building paid software for the relationship with the people that use the software. How can I build something simple that helps people live better, or even just less painful, lives in a respectful way?
These are both things you can do with free products, but it’s not quite the same. Paid products force prospective customers to consider the value and if they want to opt in. There is an explicit value exchange that sets an important tone: people pay for the product and can continually assess whether it meets their needs.1
This relationship is beautiful. It’s good for business if product makers continue making improvements and treat product users well. In turn, users help guide what goes on the roadmap.2
Now that I launched my last product and am side-project-less, I spent some time noodling about general ways to approach building paid products. I’m sure I missed some, but these all seem like decent starting points.
1. Reduce complexity
Complexity is the enemy of many things. Software loves to morph into complex, tangled spaghetti over time. One route to making a paid product is taking a feature of an already successful, yet complex product and giving it new life. Letting it shine on its own. Unbudling is a subset of this.
Doing one thing really well is often better than doing a bunch of things that are mediocre.
2. Redesign
If an old product escaped feature-complexity, it’s probably visually bloated or the design could use a touch up. Slapping a new coat of paint on the same or similar features, or even redesigning from the ground up with fresh eyes, will make it look close to brand new.
Great design is not easy, but a better design is often as simple as reducing visual clutter and sorting out hierarchy. Beware of just copying whatever design is popular or you’ll redesign again in a couple years.
3. Privacy-first
With data leaks and breaches happening more in recent years, people are becoming more privacy-conscious. Taking an existing product and making a privacy-focused version should attract some interest, especially if the existing product/industry cares very little about privacy.
You can build a privacy-focused product through marketing alone — users will feel good, but it will all be for nothing — or you can do the hard work to ensure everything is actually private. This “hard work” might be as easy as upgrading to a more modern tech stack or architecture.
4. Liberate data
Tools that help users tell better stories or make better decisions are extremely useful. Finding signals for users from their existing data or enriching their data with novel sources will help them do both of these things.
Tactically, take some data and present it in a different way, or give a group of people access to data they didn’t have before. Humans are really bad at processing and finding trends in high-dimensional data so even if the tool just prevents comprehension errors, it’s worth something.
5. Build on high-growth platforms
When new, high-growth platforms spring up, they can’t build everything for their users. Find out what these people need and make it. It might be hacky at first, but a lot of tech platforms open things up to developers nowadays. Being the first “app” in a platform’s “store” can lead to fast growth.
This strategy could also work for more mature platforms, but a lot of the low-hanging, tasty fruit will already be picked off.
6. Listen to desperate users
Given a large enough company, old enough software, or both, there are groups of folks that hate their job because they are tormented by the same piece of software every day. Find and listen to them. Those that are experiencing a “hair on fire” problem want to find a solution quickly.
Potential blockers here are the people with the acute need don’t have purchasing or decision-making power.
7. Solve your own problems
If you pay close enough attention, you can find things that are annoying about almost anything, including your daily life. Likewise, you can also notice shortcuts that others don’t. Productizing a solution to these annoyances or making shortcuts more accessible/obvious will give you at least one user — you!
If you don’t think you have any problems, ask someone else about theirs. Try to notice how they work too. Is it different from what you do? Is that better or worse?
8. Internal tools
Almost every tech company builds the same internal tools. Find out who built them and ask them why. Did their last company build the same tool? If you work at a tech company, especially a large one, there are a lot of potential customers walking around.
If you think companies won’t switch away from their internal tools and buy your productized version, you are wrong. Internal tools are often very rough and expensive to maintain. Product manager and CEOs would love to use your product if it reclaims engineering time. Maybe your current PM or CEO is your first customer?
—
Closing notes: I’ve built paid products before, but as part of large teams. There’s something different about getting paid to make a paid product and being the one that gets paid by the paid product.
Free products have more abstract value trade-offs (i.e. time/attention and instead of money) so there’s a lot less friction to amassing users.↩
Calling people that use a product users is lazy. There are other options, but since this article is very general, I’ll continue using the term. At least at Patreon, we say creator, patron, fan, etc.↩
Yesterday, I launched a quick hack I did over the holiday break: Mute.vc. It’s a simple web app where you can individually or bulk mute/unmute investors so you don’t have to see their tweets.
I posted it on Show HN, and in half an hour or so it hit the front page. Right away, traffic spiked. I was mostly unproductive for rest of the day replying to comments, refreshing the analytics, and riding the wave.
Not sure why, but at some point after bouncing around between #11-17 for a few hours, the post dropped to #45. Maybe because some people started talking about politics in the comments (think mute.politics). At that point, with traffic dying, I thought it was over.
Surprise! It wasn’t.
On a whim I DMed @vcstarterkit. They tweeted it out. And traffic took off again!
When engineers have had too much of VC twitter, they make an app to mute VCs using the Twitter API: https://t.co/hekCC7SqIV
— let me know how i can be helpful (@vcstarterkit) January 15, 2020
Some other big accounts sent out tweets, which helped even more. Notably @KristyT, but unfortunately her tweet has since been deleted. Overall, I was surprised at how well Twitter performed given I had no plan for it. Big thanks to everyone that tweeted something.
Launch aside, what was the motivation for Mute.vc? First, to be super clear, VC is important and necessary.1 What’s not super important or necessary is the thought leadership and platitudes a lot of investors tweet out.
I get why they do it — to differentiate themselves/build their brand, they miss being operators, public discussion/thinking aloud, and many other reasons — but it was tiresome, especially when I was trying to build things. The problem wasn’t who I followed.2 Rather it was all the VC content that kept surfacing in my feed via retweets, favorites of people I follow, and recommended tweets.
I was tired of having so many ideas in my mind about voice apps, the future of work, no/low code, crypto, ISAs, etc.3
After noodling a bit more, I posted the idea to my Random Public IdeasAre.na channel, and people seemed to like it. I was encouraged. I joked about it with a friend later that week and realized it would be a fun, quick hack to work on. Much to my delight the mute.vc domain was available so I got to work.
I spent a week building everything out and another week polishing until it was time to post. It was all worth it for testimonials like this:
Real. And easy! I just muted, like, over 100 VCs in less than a minute! https://t.co/MMMcaVZs5b
Overall, I learned a lot from the launch. My biggest takeaway is to “show, not tell” when it comes to a product landing page. While above average (I think), my design described what the product did with only text! Confused or curious visitors would have benefited from an interactive demo, or at least a screenshot, of the product.
Anyway, it was fun. Now, onward to the next thing!
—
Some quick closing notes: I didn’t go into implementation details in this post. You can check out the code on GitHub. Also, I didn’t talk about the launch day stats either. Here are some quick figures as of 1/18/20:
That said, there are a non-trivial number of bad investors that I’m sure are lovely people personally, but professionally, are not. They treat founders poorly, promote their own agendas/companies without disclosure, etc. all while pulling down absurdly large management fees. (Watch Chamath’s lashing if you want to rage).↩
Maybe it is a little bit who I follow. I like following people in tech. VC Twitter overlaps significantly with Tech Twitter.↩
These are all fine. Just not interested right now.↩
Due to Twitter’s rate limit and speed at which I wanted to launch, I only added 200 investors to the list. The investors were randomly selected based on who I knew and simple searches. If you are on the list and want to be removed, I’m happy to do so.↩