I decided to take a break from the growing an email list course. I have been mulling over some of the issues I had at the end of the Week of Hustle. I think that there is room to improve the concept and make it into a more robust product development framework after you are done.
Blogging and social accountability has been a strong point of the system so I think that should stay. It’s also a good way to share information on how you shape the product and keep things transparent. The issue was really in the planning stage. I had written a roadmap as instructed, but It hadn’t crossed my mind that there would be a design piece at all. That’s because I hadn’t really thought about all the tasks needed for something like “You sign up for an account.”. That sentence doesn’t really reflect all that you needed to do.
So let’s say you want to develop your own software product, what can you do to help with the process? It can be pretty overwhelming as a first timer and you might get bogged down in needless details as well. I still do. All. The. Time. It’s frustrating because you feel like you’re never making progress or not enough.
What are others doing?
Here are two methods I have come across over the past year that I found useful.
Amy Hoy’s doing things backwards
First thing you should do is think of the product in its final state and think of what you need to achieve that. Not in small detail, but in broad strokes. This idea comes from Amy Hoy‘s 30×500 class where she talks about working through a goal backwards starting from the desired goal. She has a great example in her free guide using Frankenstein.
When I first read the guide, I thought that was a very useful mental exercise. I didn’t think about it at the time, but I feel my roadmap actually used that concept pretty well. Needless to say, sometimes we do this naturally, but other times we just drive forward without thinking. You should always try to keep it in mind.
If you follow the guide, she suggest continuing to divide tasks into smaller and smaller pieces. I tried doing that a few months ago and I just thought the result was really overwhelming. You would work your way back after and it was hard to pick which small bit to work on or prioritize.
How Ryan Singer manages products
This bring me to a second useful method. Yesterday, someone posted this video by Ryan Singer on twitter and it wasn’t something quite new to me since he had written a post about it in the past. I just hadn’t thought about it in a while and, even more important, I hadn’t thought about it in the context of Amy’s guide. But I have been looking for a system to help me build Helthe. So I could stay focused and productive.
So to go back to the video, Ryan talks about individual vertically integrated scopes of work… Say what!? All it means that you shouldn’t be dividing your work per role (programming, design, etc.) as we often do, but to think about everything in terms of scopes of work. Scopes could be something sexy like a feature or something less sexy like authentication. I put a screenshot from the video to help illustrate the idea.
The other important element of the scopes is that they are generally very self-contained. You might have a dependency (like registration depends partially on payment in his example), but what is really nice is that once you have done all the tasks for a scope. It is really done. You don’t have to go back to it. Which is what was missing from Amy’s guide.
Deciding which scope to use is based on learning opportunity. Which scope will force me to ask the most questions about my problem domain and allow me to learn the most about it. As a programmer, we tend to gravitate towards what is the most fun to code or the easiest.
A formal attempt
So let’s try to formalize a system we could use. I would also say that it is probably useful to blog about all of this. Social accountability is a strong motivator. That’s my plan at the very least. I’ll go through my proposed steps using Helthe as an example.
First, I would work backwards from my desired outcome and develop a high level map of what I want to build. Ask yourself what do you need? So Helthe is an application error monitoring service for PHP. What do I need to go in Beta? I came up with this map. You might notice that I don’t have marketing site there. Not sure if it should be or not. It’s not part of the product per say and it’s not something I would want to tackle until I understood your problem domain completely.
Second, I would find the scope of work that offers the largest learning opportunity. Honestly, I didn’t find this step easy at all. Initially, I thought maybe the dashboard or the project itself, but Helthe is about errors so I decided that the whole error management system (grouping, displaying, etc.) really forces me to ask some tough questions about the domain.
Third, I’d divide your scopes into tasks. They should include everything you need to check off that scope as completed. You can do it without a process, but I would go at it backwards the same way you came up with the map. If you come up with a lot of tasks then it might mean that you need to divide things further at the high level.
Should you do it for every scope right away? I am not sure. It seems to go against the idea that if you are going from the largest learning opportunity, it might impact the task lists for the other scopes as you answer questions about your problem domain. You could probably start with an initial list though.
I purposely left my task list out because I didn’t have time to think it through completely. I also I feel it deserves to be a post by itself (probably my next one). Each scope should be its own post.
All that is left is for you to go through each scope one by one. You’d pick the next scope by continuously asking yourself which one offers the largest learning opportunity.
I’ll be exploring this further
If you’ve liked what I have been writing and want to hear more, you can subscribe to my mailing list here! I have been writing a lot so I am still figuring out how to approach things for the list. You can also keep checking the blog every day if that’s your thing!