If I could go back in time and give a younger me one piece of advice when starting my company, it would be - don't start a business, build a side project instead. Build it for fun, see where it goes, let curiosity be your carrot as opposed to the expectation of success being a stick.
Side projects are simple. In fact they're so simple that you work on them just for the fun of it. You get deep into it, with no expectations, let what you learn evolve what you do next and let the project basically pull itself out of you.
When you start a business there is an expectation of success attached to it, otherwise the business is a failure. You need to find a business model, figure out what your vision is and what the market size is. "Is it a big enough idea?" is often the question asked by friends, parents and investors. There's nothing more demotivating than talking about your business to a cynical aunt.
Secondly, you need to be able to sell your ideas to those around you, and do it without fear. The best way to shed the fear of appearing foolish is to actually do something foolish for the fun of it. Strangely, you'll find that everyone around you is a lot more encouraging in this scenario than if you set out claiming you're going to build a big business.
Big things are accomplished by the compounding effect of many foolish little things done over a long time. If you start off trying to do a big thing, you'll always feel unaccomplished because you're too focused on what you haven't achieved yet. Focus on the small things, work on little projects, make an app for your friends as a joke, file your aunt's taxes, write a blog, build a shitty robot. Keep doing that and just enjoy the process of building and creating things, and keep that child-like sense of curiosity alive.
The main reason for this is that you need to do the groundwork to prepare yourself to be receptive to opportunities when they come up. You never know when they will, but unless you are knee deep in something you love already, you just won't notice it.
“You want to know how to paint a perfect painting? It's easy. Make yourself perfect and then just paint naturally.”
This tutorial is for anyone setting up a "self hosted" Ghost instance, not Ghost Pro users.
Ghost is a fantastic open source blogging platform that combines simple design with a ton of flexibility. It's basically Wordpress without the bloatware and plugin hell and if you like to tinker with web development, it gets infinitely more fun to play with. They also have a membership feature that lets you create email newsletters (similar to Substack or Revue) which is what got me interested.
I recently set up a self-hosted instance of Ghost for this blog and wanted to set up an email newsletter subscription with a custom sign-up form. I initialize assumed I'd need to design a custom theme to do this, because the Ghost documentation on custom signup forms is in the theme documentation, but later realized I could have done it entirely in the post or page editor. Of course, if you want to do fancier things like control access levels, enable sign-in / sign-out or have custom member profile pages, you'll want to start messing with the theme files, but if you're just looking for a basic subscription form to capture emails, there's a simpler way to do it.
There's a few gotchas along the way that I had to do some digging to figure out so this post compiles everything you need to do to get a simple custom subscription form working for your blog.
Disclaimer: Ghost has a new feature called "Portal" that lets you add a popup subscription form to any theme, but I wanted to customize the design a little more and decided to create my own form.
What you'll be able to build:
A custom email form like this. (This is my live working signup form)
When a user signs up, they will get an email asking them to confirm their subscription. When they click the confirm link, the will get added to the members list in your blog. You can then start sending them emails.
From the Ghost member documentation, the simplest sign up form looks like this. There are two required elements for an email signup form — an email input field and a submit button. Use the data-members-form attribute for the form element and data-members-email for the email input field to create a standard email collection signup form.
Setting data-members-form="subscribe" tells Ghost to send a subscription confirmation email when someone submits the form.
To add this you can simply add an HTML block in on any post or page (e.g a subscription page) and add this in.
Next, Ghost changes the state of the form element based on the status of the form submission. The states are: "loading", "success", and "error", and you can handle those states with 3 message elements and simple CSS that conditionally hides or shows messages based on the form's state.
First append the status messages to the end of your form like this.
<input data-members-email type="email" required="true"/>
Sending confirmation email...
Great! Check your inbox and click the link to confirm your subscription.
Please enter a valid email address!
Then, in the < > Code Injection section, in the Ghost admin, add this in the Site Header.
This CSS will basically hide the div elements with status messages unless the state of the form (managed by Ghost) matches the div class.
2. Enabling the members feature
In Ghost Admin, under "Labs", go into the Members section and toggle "Enable Members".
The new Portal feature might turn on automatically so since we're building a custom form, we'll enter Portal Settings and turn off "Show Portal Button".
Also turn on "Allow free member signup".
3. Email Configuration
Now open "Email Newsletter Settings" and you'll see this.
Ghost uses Mailgun (which is a paid transactional email service) for automated emails like subscription confirmation as well as the email newsletter. They do have a free tier for sending less than 1000 emails per month and they have reasonably good pricing but you will need to pay for it.
Are there other options than paying for Mailgun? You can use other email newsletter platforms like MailChimp or ConvertKit if you find their pricing more favorable, and you can embed their signup forms on your pages in the same way. However, you'll need to manually send each post out through your third-party email service provider. If you want to separate your newsletter content from your blog content this isn't a big deal, but I wanted to automatically email every post I write to my subscribers.
Setting up Mailgun
If you've decided to go with Mailgun, follow these steps. Remember that there are two things we're going to get Mailgun to do.
Send your actual email newsletter
Send transaction email like subscription confirmation messages - Ghost can use nodemailer to send these emails out if you don't configure Mailgun to do it, but I recommend setting up Mailgun because nodemailer is less reliable and you'll need to manually install nodemailer if your server doesn't already have it.
Under the Domains section click Add New Domain. (Hint: copy the password, you will need it later)
Enter the domain from where you want to send the emails. Mailgun will recommend setting up a subdomain like mg.yourdomain.com to send emails from.
Update your DNS records according Mailgun setup instructions. This step adds the SPF and DKIM records that authenticate Mailgun to send email for you.
Add Mailgun credentials in Ghost Admin
Go to the Members section and expand Email Newsletter Settings.
Fill Mailgun region and Mailgun domain, from your Mailgun account.
Fill Mailgun API Key. You'll find the API key in your Settings > API Keys panel in Mailgun. Pick the "Private key" and paste it in Ghost.
To test this, open any post and go to the Post Settings and click Email newsletter. You can set an email where you want to send the test email. Then click Send test email.
Transactional Email Configuration
Next step is to update the configuration of Ghost on the server to send transactional emails through Mailgun. This is needed to send confirmation emails to anyone who signs up for your newsletter through your form. They don't get added as a member until they click on the confirmation link so it's critical that they receive this email.
Get Mailgun SMTP credentials
First, in Mailgun, navigate to Domain settings under Sending. There you’ll find your SMTP credentials. This is different from the API key you found in the previous step.
In addition to this information you’ll need the a password, which can be obtained by clicking the Reset Password button. Keep these details for future reference.
Add credentials to config.production.json
Open the config.production.json file from your ghost root directory in any code editor and add the following mail configuration, making sure to update the values to the same credentials shown in your own Mailgun SMTP settings:
The user is the email address shown in Mailgun under "Login".
After adding all the settings and saving the config file, restart Ghost:
And that's it! You can now try signing up in your newly created form. You should get an email in your inbox to confirm the signup and on clicking the confirmation, the member gets added to your member list.
I wrote about the risks of falling in love with your own product in an earlier post, and it led me to think about some of the product management mistakes I've made in the past. As an engineering grad student turned startup founder leading a team of engineers, I have a not-so-insignificant tendency to get tangled up in the excitement of "what can be built" at the expense of answering "what should be built?".
A while ago, I realized we needed a simple (and possibly stupid) mental model to evaluate product ideas and keep the conversation focused on the most important things. It might sound painfully obvious, but if it were truly obvious there would be no failed products. So I thought I'd write it down.
Whenever we're evaluating a new product or feature, we ask ourselves the question:
"Are we building a bridge or a monument?"
It's a pretty simple analogy.
Bridges come in all shapes and sizes. They can be beautiful and majestic with multilane highways, bike paths and railway lines or they can be small, like a tiny footbridge or a plank of wood. The important thing is that no matter what their features, bridges do one thing - take people from point A to point B. Strip away all the bells and whistles and what you're left with is a log of wood stuck across a stream. Seems unassuming but guess what, the 10 people who live on side and work on the other, use this log every single day to get to work and can't live without it.
A monument, on the other hand, is glorious and majestic. It stands tall in a beautifully scenic location. Everybody knows about it and everybody believes it's THE landmark of their town. Hundreds if not thousands of people visit it with their friends and family, and marvel at its size, beauty and intricate architecture. They visit, take lots of pictures, have an incredible day and then leave...and never come back.
Often, when building products, teams have a strong tendency to build monuments. The perfect combination of features and technology, with a sleek UX that could win a design award. The problem is, when push comes to shove, unless the product does the job of getting people from point A to point B, nothing else matters. That person who lives on one side of the stream, doesn't care about the elegance of your architecture. They just want to get to work.
In product terms, monuments have a high churn rate, while bridges have a very very low churn rate.
When I think about building an MVP, I now think about that plank of wood. If I built the simplest, scrappiest version of this product with no extra features, will it:
Get a user from point A to point B? (Does it solve a real problem?)
Will 10 people find it valuable enough to use it everyday?
"If you're creating a new product, what are the three (or fewer) key features that will make it so great that you can cut or half-ass everything else? Are you focusing at least 80% of your effort on getting those three things right?"
Note to self - Build bridges, not monuments.
Do you have any other mental models you use to help stay focused on the right problems? I'd love to learn about them! I don't have comments enabled yet, but you can let me know on twitter!
Falling in love is dangerous. It makes you irrational, moody and stupid and more often than not, sets you up for pain in the future. Its also feels incredible and makes life worth living. As it turns out, this isn't just true in relationships. It's also true in product design.
Everything that gets you excited to wake up in the morning and work on a product or a business, and makes your product worth the effort, puts you at the risk of becoming an irrational, moody and stupid product designer. It usually starts with an inspiration. An epiphany, a sudden aha moment when you feel like everything has suddenly clicked into place and the fog has lifted. You start gathering feedback and interviewing users, but your confirmation bias is like an irresistible sunrise you can't look away from. Soon your mind is knitting together a story of your product into a vision that's so huge and significant it's almost zen-like.
I've suffered from this in the past and still struggle to resist the urge everyday. As an engineer turned CEO, the hardest part about leading a product team is balancing obsession with rational decision making. Don't get me wrong - obsession is important. It's the strongest driving force for creation in history. When a person is obsessed, there's nothing they cannot do. In product design, however, this is a double edged sword. The side effect of becoming obsessed is that it acts like horse blinders, narrowing your field of view, making you oblivious to your blind spots and prematurely focusing you towards a singular vision. The problem is that in the early stages of product development, your peripheral vision usually contains the most important and useful insights. You will inevitably need to course correct during the product design process and you might even need to pivot.
So how do you recognize this tendency and help yourself avoid it? Here are 5 steps I've taken to keep myself rational during the early stages of product design.
In my experience, the first step is acknowledging this tendency in your team and deliberately treating a new product idea for what it is - a hunch at best. It's hard to keep a team motivated to build a product without getting emotionally attached to it but the goal with any early stage product discovery process, is to learn as much as you can about the problem and the user, and then figure out all the possible ways to solve it (which may or may not look anything like your initial inspiration). You need to be open to several alternatives for solutions, not just the ones you are most comfortable with developing.
Don't get fixated on a product direction as a manager and don't dismiss ideas from your team that aren't clearly aligned with it. Ideas are fragile. They need to be nurtured. Often the most bizarre ideas, or a fleeting afterthought, tend to become your biggest idea with just a 10% tweak. Don't ignore these fleeting thoughts because they are your team's peripheral vision kicking in to save you from yourself. Give them the attention they deserve.
Caring more about the problem than the solution is easier if you, as the product leader, are a target user of your product. If you're a robotics engineer working on a construction robot for example, you're naturally more excited and knowledgable about the robot than the construction. This is a dangerous combination and can lead you to make bad product decisions for 2 reasons. (1) You might try to shove a robot solution into a problem that might not need one right now and (2) If all your knowledge about the problem comes from user interviews, you can either get caught up in confirmation bias or kill a good idea because you got some negative feedback from the wrong person early on. An easy way to solve this problem is ensure that your product team has at least 1 or 2 discerning target users of the product. If this isn't possible, forget about the product for a while and spend some time working alongside or shadowing your target user. Naval Ravikant (founder of Angellist) has a good quote. "To write a great book, you must first become the book". This holds true in product design as well.
Perfect is the enemy of done. The more you fall in love with your product, the longer you'll likely take to release it. You never feel like it's ready. Later in the process, if you learn you need to pivot, you feel like you're abandoning your baby. Try to avoid trying to build the perfect product. This doesn't mean your first version should be terrible, but it should have an almost comically narrow scope. Reduce the idea to the smallest possible version of the product that will still accomplish a goal for users and then do a great job at it. Paul Buchheit has an article that I come back to often - "If your product is great, it doesn't need to be good".
Lastly, don't overthink it. Don't get stuck in an endless cycle of brainstorming meetings. Just try it. Get your MVP out to people, but be willing and open to fail or learn that you're wrong. I've found that very often, users don't know what they want until they start using it. This makes user interviews very very difficult because you're never sure how much to trust the interview. An antidote to this is to treat an early product experiment as a side project and get it out to users before you've analyzed every problem that might come up with it. At the same time, be mindful of what you don't know and deliberately list your "unknowns" as a list of questions you need to answer through the product discovery process. Prioritize the questions that could have the biggest impact on the product and try to de-risk them first.
Jon Stewart has a quote that stuck with me. "Have a clarity of vision, but a flexibility of process". I've realized over time that "vision" in the product design sense can mean many things depending on how you define it. Vision is a great motivator, but in the earliest stages of product development, I think it's overrated. What I mean is that prematurely attaching a vision to an idea can be deflating if your assumptions are wrong. Conversely, if a small side project you are building starts gaining traction you can almost always project that story into the future in any way you want and get excited about the big vision. Incidentally, this is the story of some of the biggest products around today. Uber, Facebook, Twitter, Instagram etc.
Of course, this is easier said than done. In times of uncertainty, we want to latch on to anything that promises stability and so the urge to settle on a product direction quickly is huge. Depending on the size of your team though, setting the wheels in motion too quickly can derail you and burden your team with unwanted inertia, when what you really need is to stay nimble.
There's no shortage of books describing the process of product design, but I find that the hardest part is not following the process, but exercising the emotional detachment to be let yourself honestly follow the process. Hopefully, this set of principles I've had to learn the hard way, will be useful to you and set you up to be a rational product designer.
PS: I'm starting to write weekly articles about topics that interest me. They tend to be loosely related to product design, startups and hard tech (robotics, A.I., computer vision etc.). To get updated when I publish my next article follow me on twitter @neilxm.