Two years ago, when I quit my job at Quora to write my first book full-time, I didn’t really know what I was getting into. I had a romanticized notion that I’d travel around the world for a year, sipping lattes at cafes and happily typing out chapters, and then come back with a book that readers loved and that made a meaningful impact on their lives.

Reality followed a different path. Writing and traveling didn’t mix well for me. I’m too tempted to explore my surroundings while traveling to maintain any consistent writing schedule, so my best writing happened while I was home. Moreover, writing a book turned out to be significantly more complex and taxing than composing a series of long blog posts. From putting the first word onto paper to launching the paperback and digital versions of the book, the entire journey to complete the 77,225 word manuscript took me 22 months — nearly twice as long as I originally expected. And while writing was certainly rewarding overall, it was also at times painful, lonely, and frustrating.

One aspect of my original vision that did materialize, however, was making a meaningful impact. Less than two months after self-publishing my first book, The Effective Engineer, I sold my 1,000th copy. And the stories from readers about how the book has changed their careers inspire me to do more.

Getting to this point wasn’t easy, and the 2-year long journey taught me many lessons about successfully shipping products that have stuck with me now that I’m working at a startup again. These are the stories of mistakes I made and the most valuable lessons I learned — lessons that might help you to ship your own products.

1. Own the problem and the results

I love to write, but less than half of my time shipping the book was actually spent on writing. With traditional publishing, a publisher takes care of most non-writing-related responsibilities for you. But with the self-publishing route, I had to own the entire project.

As I would learn along the way, self-publishing involved: defining the target audience and market; conducting user research; interviewing experts; writing the book; hiring a professional editor; contracting a book cover through 99designs; hiring a cover designer to replace the low-quality 99designs cover; learning about typography; laying out the book; building tools to produce the book; beta testing early versions to collect feedback; determining pricing and packaging; marketing the book; developing and executing on a launch plan; and much more.

In many ways, self-publishing a book is like shipping a product. Just because you write a book doesn’t mean that it’ll publish or sell itself. Just because you build a product doesn’t mean that people will use it. And yet oftentimes, we prefer to stay within our comfort zone, thinking if I just write the code, someone else will take care of deciding whether I’m building the right feature. Or, if I don’t fix this bug, someone else will. To succeed, you have to own the problem and the results. You have to ask yourself, what needs to get done for this product to succeed? And then you have to do it.

2. Conquer your fear of feedback

Perhaps the costliest mistake I made while writing the book was not seeking feedback early enough. I polished first drafts of my initial two chapters for two entire months before showing them to anyone — all because I feared what people would say. What if the writing wasn’t good enough? What if they told me it was a stupid idea to quit my job to write a book? What if they discouraged me enough from actually finishing? As long as I didn’t show anyone what I had written, I could keep writing in a bubble and pretend that everything was going well. Of course, great products don’t get built that way.

When I finally polished the drafts enough to share with some trusted reviewers, their honest feedback taught me so much. They shed light on what was useful and not useful, and just as importantly, what was missing. They pointed out which stories resonated with them and which ones they found dull. And I ended up restructuring and scrapping large portions of what I wrote to produce something even better.

My initial fear cost me time, time that I could’ve either shaved from the 22-month timeline or used to create more value. If you want to create something high-quality, you need to be honest with yourself and face that fear of feedback.

3. Seek the shortest path to feedback

After reading a first draft, one reviewer commented that “the writing felt like it was second draft material.” That comment raised alarm bells, because it indicated to me that I had started polishing the product too early. If I had to change it — and I did — that polish would go to waste.

In retrospect, I should’ve applied what I do in software engineering to book writing: figure out the shortest distance — the minimal viable product — to validating my work. I could’ve, for example, sketched out an introduction to motivate a chapter and then outlined the major points and examples I planned to write. That outline would have allowed me to validate my approach sooner without investing nearly as much effort.

When building any product, the more time we’ve invested, the harder it becomes for us to overcome any emotional attachment to our work. That, in turn, makes it harder to acknowledge any investment as a sunk cost and change directions. Had I solicited feedback on an outline instead of a polished draft, I would’ve been less emotionally attached and could’ve shared it with more people earlier and more frequently. That change in mindset alone would’ve saved me many months of time.

4. Turn your progress into a habit

For the first 10 of my 22 months, I took an unsalaried, personal sabbatical away from software engineering to focus on the book full-time. The flexibility was liberating — I took full advantage of it to pay down sleep debt accumulated over many years of long startup hours. But the lack of structure was also risky — I might look back months later and have little progress to show.

And so I imposed my own structure. I made a habit of working on the book every day, even on weekends. Even after I started working at my current startup Quip, I would get up at 7am on weekdays so that I spend 2 hours on the book before catching the Caltrain to work. I didn’t always succeed at maintaining my habit — travel, job interviews, and sometimes plain tiredness would get in the way. But the habit turned out to be critical, as the daily momentum made it easier to make some progress every day.

5. Do the hardest tasks when you have the most energy

As a software engineer, I’m often at my desk for 8 hours a day building software and find it a fairly sustainable pace. And initially, I made the mistake of believing that I could apply the same work ethic toward writing. But I quickly found that writing consumes so much mental energy that I would hit greatly diminishing returns after the first 3-4 hours. Words would stop flowing, and I would start fidgeting in my seat.

On any large project, it’s critical to manage your energy. Schedule mentally difficult tasks like creative endeavors or prioritization at the start of your day when you have the most energy, and save lower-energy tasks for later during the day. To actually work beyond 3-4 hours per day on the book, I had to switch to less draining but still important activities — researching the self-publishing process, designing the book layout, organizing reader feedback, etc. Sometimes, I even had to do something else entirely to recharge, like go for run.

6. Seek out mentors and experts

I knew from the start that publishing a book would be a challenging and ambitious project. I had composed lengthy blog posts before, but I knew that drafting and publishing a 250+ page manuscript would be an entirely different matter. So how did I even know where to begin?

By seeking the advice of mentors and experts. I read Nathan Barry’s Authority and Guy Kawasaki’s APE: Author, Publisher, Entrepreneur, books written by authors for other authors considering self-publishing. I met up with authors who had successfully self-published books for engineers, people like Gayle Laakmann McDowell (Cracking the Coding Interview), Alex Allain (Jumping into C++), Piaw Na (An Engineer’s Guide to Silicon Valley), and many others. I asked them about the biggest surprises they encountered when writing a book, the parts that took longer than they expected, which areas I ought to spend more resources on, and specific tactics they used.

I could have stumbled along and learned those lessons myself, but their advice likely saved me months of trial and error. Reach out and learn from people who have done what you’re doing before.

7. Build traction and relationships with users as you go

When I first started working on my book, I had no mailing list. 22 months later, I launched the book to over 4,000 email subscribers. And that list allowed me to jumpstart my initial sales.

Having worked for a few years on user growth at both Quora and Quip, I knew that simply writing the book wasn’t enough. Just like most startups fail, most books don’t sell. The mentality “if you build it, they will come” is a broken one. Posting articles on this blog even as I wrote the book not only provided me a great platform to incrementally vet some ideas but also enabled me to connect with readers and build a mailing list in preparation for launch.

Like with any product, shipping The Effective Engineer is really only a first step toward a meaningful impact. There’s much more to do, and I’m excited to keep investing in resources that help others be more effective engineers.

If you’re an engineer, get the book and the interviews to shortcut some of the lessons and mistakes that engineers at top tech companies took months or years to learn. Learn what investments Mike Krieger (co-founder of Instagram), Bobby Johnson (former engineering director at Facebook), Marc Hedlund (former VP of Engineering at Stripe and Etsy), Yishan Wong (former CEO of reddit), and other engineering leaders have found to produce the best returns on their teams.