This week, as I spent my free time perusing the infinite feed of fun that is Twitter, I stumbled across this Tweet from Adam Wathan looking for "anyone with a non-chronological, non-blog website where they post guides/tutorials/articles/whatever."
I took a look at the example website that he provided, read over their rationale for having a "Guide-Driven Blog," and was instantly smitten with the idea.
Two of the most significant problems I have with my blog posts is that they fade away over time and that it's difficult to continue a theme across many of them. Apparently, this has been an issue for a lot of folks, and they've started using guides to organize their content.
This approach is fantastic because it naturally produces logical groupings for our content while also providing time-proof slots for them to live. Plus, they offer good-looking readers - like yourself - better accessibility to the content that they're most interested in reading.
I had been contemplating writing a series of posts going over how to build a regular blog because it's a great starter project that covers such a wide variety of concepts. But, by this point, they've been covered enough.
With this new spark of inspiration, we have a project that covers those same concepts, and many more, in a brand new way.
This series of posts will be a soup to nuts walkthrough on planning, designing, architecting, building, testing, styling, launching, and many other gerunds. In short, we're going to cover everything piece of making a project from scratch, and I'm super excited that we get to do it together.
The First Step Is The Most Important
In the past when I've started projects, I've found myself getting overly-excited and doing a bunch of work for two weeks and then never touching the project again. Talking with my friends and looking around on Twitter leads me to believe that this is a common problem.
Over the years, I've had the chance to reflect on my projects that did end up getting finished, and the thread that connected them all was planning.
For a lot of folks, this sucks. You're motivated, you're excited, and you just want to build the damn thing. I get it - that's how I am too.
But, after two weeks that motivation will be gone. All of those great ideas that were so crystal clear will fade. Life, work, and the rest of the world will tug at our attention. And soon, we'll be sitting there with nothing to propel us forward.
Plans are our kindling in those dark moments. Especially if we took the time to plan out what will motivate us in the future.
Now, there's a big difference between starting a fire with birch bark instead of wet newspaper. That's to say, any plan is better than no plan, but there's nothing quite like a great plan.
Great Plans And Where To Find Them
So, we're on board with the idea of planning, now what makes a plan great? A great plan articulates a vision, identifies the riskiest components, and provides a way to execute.
Having a vision is probably the essential piece of this puzzle. A vision gives us a sense of purpose, which is crucial for motivation. It also provides a reference point in the future that we can measure all of our current progress against.
Risk is also important. There will be things that are really out of our control, the biggest being how other people will react. Having a working idea up front of what our risks might be can save us a lot of heartburn in the future. Not just because identifying them can help us avoid them, but mostly because having an idea of what to do in the middle of a hectic moment is far better than having no idea at all.
Finally, we can make all the plans in the world, but if we fail to execute them, they're worse than useless. We can avoid this trap by putting on our project manager's hat and spending some time figuring out how we're going to accomplish our vision.
If this is what a great plan should be, then how do we make that happen? I follow a pretty simple checklist that I've developed over the years, that looks like this:
- What's the big idea?
- Who is the audience?
- Why is this worth building?
- For us
- For our audience
- What are the user flows?
- How is the data structured?
- What does my execution stack look like?
- How will I execute this project?
Yours might be a little different, and that's alright. The important thing is that your checklist covers the big three concepts we just discussed: Vision, Risk, and Execution.
In this checklist, items 1, 2, and 3 relate to vision. What is that big-picture, 10,000 feet in the air view of what we'd like to accomplish, who is that for, why should they care, and why do we care?
Items 2 and 3 also cover our Risk section. The riskiest assumption we'll ever make in any project is that we're building the right thing for the right people. So, taking the time to think and identify that audience is critical to our success. As the Lean startup folks say, "life's to short to build something no one wants."
That said, a perfectly valid reason for building something is because you want to build it. That's why I like to make the distinction in point 3 between the general audience and ourselves. If this project is worth building to you, then that's all the reason you need to freaking build it!
Lastly, points 6-7 all deal with our execution. Now, since I'm a developer, I use developer terms like data and user flows. But, those concepts can apply to any project.
If you're going to brew beer, then the user flow is open beer > drink > ah > enjoy! If you want to sell cupcakes then it's: smell delicious aroma > enter store > select tantalizing cupcake > buy 6 dozen > enjoy!
We can trap ourselves into thinking that user flows are just about how folks interact with software. But, if you take a step back, a whole new world of possibilities open up - and that's where the opportunities are.
Data has a similar issue. What kind of data does a brewer need? Let's start with a recipe, then production output, then sales volume, then customer satisfaction. Again, when we just take a moment to think, we can see that almost everything has some form of data associated with it even in its simplest forms.
Thinking about this up front helps us crystalize what exactly we want to build, which gives us a target for our execution. If we decide we want to make chocolate cupcakes, then we shouldn't go out and buy a bunch of jelly beans!
Now, that we're starting to translate our vision into something tangible, what does our execution stack look like? Or, in other words, what tools, marketing, and people do I need to make this thing successful?
Sometimes our tools can be as simple as some brewing equipment. Other times, we're talking about setting up a headless CMS that talks to a mobile and desktop app, which needs to support multi-tenancy - you get the picture. But, in both cases, we're taking the time to figure out what it's going to take for us to get our project done.
Marketing gets a lot of puzzled looks, and I get it. It doesn't have the best reputation. But, what I mean by marketing is taking a moment upfront to think about how we're going to share with our audience that what we're building is valuable to them.
For our brewer, that could be calling up 10 buddies when the beer is ready. Sometimes it's an international roll-out with a social media blitz and supporting touchpoints. Again, the scale is up to you, but having an answer will help you share all of the hard work that you've been doing.
Now we're on to people. I don't think I've ever worked on a project entirely by myself. Even those crazy bootstrappers on Twitter are lying when they say they built their project alone.
At some point, we've all had a friend or a family member review some text, tell us we're on the right track, or provided some constructive feedback. And that's phenomenal - it's what reality looks like.
Taking the time, in the beginning, to identify and even reach out to the people in our lives who can help us will help us succeed in the long run. Looping them in at the beginning means we can reach out later and they'll already be invested enough to help. And if we're fortunate, they'll be interested enough to keep us motivated along the way.
Finally, we have our execution plan. Whether you use Scrum, Agile, Waterfall, post-it notes, GitHub, or some other project management resource, it's time to set that up. Since there are so many ways to do this, I'm going to let you do you.
My only recommendation is that you keep your tasks actionable, measurable, and small and that you don't plan too far in advance. No one has a crystal ball, and planning too much too early can prevent us from adapting to new circumstances when we need to.
Now that we know how to create a great plan let's run through the checklist and plan out our guide-driven blog.
Planning Our Guide-Driven Blog
1. What's the big idea?
We're creating a guide-driven blog that organizes its content better for readers so they can consume the content that matters most to them.
2. Who is the audience?
This project will have two audiences: readers and admins.
3. Why is this worth building?
1. For us
We get to alleviate our two biggest frustrations with a traditional blog: having blog posts fade away over time and being unable to continue a theme across many of them.
2. For our audience
Readers get to read content that is better formatted for their individual needs. Admin users can easily maintain and update the blog with guides and content.
4. What are the user flows?
For readers: find blog > find guide that suits their interest > read posts that interest them > continue reading guide or find a new guide
For admins: create a new guide, create new posts, connect guides with posts, upload media, manage other admins, and see overall stats.
5. How is the data structured?
We have four core pieces of data: admins, guides, posts, and media.
6. What does my execution stack look like?
We'll be using GitHub, TDD, Laravel 5.6, Vue.js, Tailwind CSS, and, more likely than not, a bunch of Spatie packages.
I'll be writing blog posts that document the whole process, and I'll also be sharing our progress on Twitter. Plus, I'd love if you could share it too!
Naturally, I'll need your help to let me know if I have a mistake in my code or if I could explain a concept better. I'll also be reaching out to the community on Twitter if I need specific help.
7. How will I execute this project?
We'll be using GitHub for our project management so everyone can follow along.
Our first few steps will be: figuring out the UX, creating some wireframes, upgrading to mockups, setting up the project, scaffolding the backend, and then developing features.
I plan to devote some time every Sunday to work on the project itself and then write up the corresponding blog post on Monday and Tuesday.
Bada bing bada boom, we've got ourselves a plan. By taking this time in the beginning to figure out our Vision, identify the Risks, and map out our Execution we've equipped ourselves with a better understanding of our project and a clear path forward.
I can't wait to see where this project will take us, and I'm looking forward to all the questions and insights we'll have along the way. As always, feel free to ask me any questions on Twitter. And until next time, happy planning!