Don’t teach how to write an entire app.
End-to-end process for someone to be able to put together the first feature. The win is not the app, it is one small feature. Seeing that working is addictive
==> Teach how to write a single feature. Every feature accomplished then pulls you along to the next.
Marjan: Interesting that Justin does it like that. It is something I have been considering to teach myself asp.net mvc/webapi: one feature of a site at a time and writing posts as I go along.
Influenced by: Pragmatic programmer
Varied a lot, little bit of time every day. usually 1 hour or 2/day for the book 3-4 days/week; plus between 2 and 4 (a day) for writing blog posts and email newsletter and all that other stuff
Routine started with a blog post every tuesday morning; then added an email newsletter every friday morning. Became sacred. Helped balance the rest of the work and keep the book from overpowering the rest.
Hardest: writing specific posts that actually solve a problem without pulling in all sorts of related problems, or making the answer so generic that it doesn’t help anybody.
Scrapped his book twice before “sticking the landing” for the same reason – realised his book was based on too little safari to really know what his audience wanted and needed and that led to stuff that was exactly like every other tutorial out there and worse. The feedback he received on blog posts and newsletter items, told him that the problems his audience faced were not related to what those tutorials addressed at all. Took about 3-4 months of ebombing, safari, chatting with people on his list, to realize it. After that it was much easier to write and finish the book.
Amy’s 4-part-guide on building your first product (around end of 2013) <== helped
Doing more safari allowed him to get closer and closer to the problems his audience was facing. Making his ebombs resonate more etc.
Before launch in feb, list was 1900 subscribers. Started from zero. Took 3-4 weeks to get to the first 50.
Turns out that SEO traffic converts better to subscribers than traffic from reddit and the like.
Alex point to Justin’s ebombs as examples of excellence. He hits every mark. They are crispy, specific, helpful, actionable, Justin’s personality shines through. They are consistent.
There is a formula. Helps him write them.
– Problem statement from safari. Question. Crazy problem. Tweak them to make them stronger.
– Explanation of the solution.
– Wrap up “Where would you use this”
Outlines first to keep him on the straight and narrow.
Nobody ever called him out on “Justin all your blog posts are the same…”
Has heard from people who land on his site and then read everything that’s there.
“This is a problem I thought only I was having, how did you know?”
Post on new things in Ruby are like candy posts: fun to read but you don’t get much out of it. Justin tries to put something in every post that you can apply.
Launch: two launches
Presale in october for the first (actually second) draft book, 900 people on the list, writing started in June. PDF only.
Shipped updates every three-four weeks.
Second was actually shipping it.
Presale: 2500 for the first day.
By formal launch 12500 in pre-sales.
Formal launch 5500 on the day / or around 72 hours.
Almost everything from list or referrals by subscribers.
Total to date : breaking 20000 real soon.
Sample chapter technique
at the end: if you want the full version, get it here, landing page of the book. Later expanded to include full info on what else would be in the book and what that would get you.
Would have done differently: a lot smaller!
Didn’t have to start as a book.
Wasn’t very good at figuring out what people’s problems were which led to wasted words – both in the book and on the pitch page(s) which meandered too much: here’s a problem, here’s another problem, and here’s another one. Locked him into a direction he might not have taken had he started (again?) from scratch.
==> Even though it looked like he had a handful of problems that were related, it was still to spread out and he would have done better zeroing / locking in on one.
There are many different ways to kill the same pain, even for the same audience. Getting locked into a single format, whether it is a book or a course… Those are just some of the options.
It is sort of the intersection of what solves the pain, what do they buy and what were you able to create with the most reasonable – because least is not necessarily the goal – amount of time and effort. The intersection of those is the sweet spot Justin could have bulls eyed more.
Justin “reset” at a certain stage and created a pitch page for a different product without the intention of creating it, but in the process giving himself a win “I did it, I can do it”. Go back to the work clearheaded. When he went back to his safari he realised he had missed a lot the first time.
Cherry picked the 30×500 process, skipping steps. Second time he didn’t skip and did all the stuff, not just what he liked or was comfortable with.
Current challenges:
- Tends to see patterns that aren’t really there.
- Makes up that stuff is related when it isn’t.
- Figuring out what the core problem is.
Take aways from having a product for sale
- None of the mental roadblocks exist any more. Everything he was worried about of never came to pass.
- Opened a lot of doors to what he thinks he is capable of
- Listens a lot more. Hears problems much earlier.
- Whenever he tries to write something he starts from that problem and what is the way we can fix it that actually solves the problem and isn’t just what he wants to build.
- Asking the right questions that aren’t like “ok what is your problem” but trying to zero in on that by asking them more to describe how they are feeling what that is leading to.
Leave a Reply