How to Kickoff a Software Project

I love the first days of a new project. I really enjoying breaking down the problems we are working to improve, figuring out the first pass of a user interface and starting a new project repo. It’s a great time to execute new code patterns and experiment with new project practices.

Today we’ll explore some tips and recommendations regarding kicking off a personal software project. I’ve focused on personal projects rather than client projects to match the focus of this blog. Some ideas are universal but others require a lot of buy in from the client. Maybe some day in the future we can chat about this topic from a consulting / client angle, until then enjoy the freedom of launching your new project your way!

Documenting Your App’s Mission Statement

Being able to share a short, focused mission statement that describes your app’s goals is an incredible tool regardless if this is a solo endeavor or something a whole team will work towards. This is a mission statement that will be at the heart of your marketing. Reading this mission statement will help squash arguments over what features deserve priority. This mission statement will drive the project.

Documenting Feature Ideas

Once you have a mission statement then it’s time to do a feature idea brain dump. You may have started this during the idea evaluation phase but now is an opportunity to do a second pass and organize your thoughts.

In my own experiences I’ve done my initial brainstorm in a plain text editor, just listing my ideas as they came to me. For my second pass I would transfer that list to a more organized tool like Trello. I use Trello and group the ideas into categories (or columns on the Trello board). I then go into a card for a given feature and document deeper thoughts and/or URLs to related resources.

The idea at this phase is just to get ideas out of your head and into a trusted system. Don’t limit yourself to ideas for version 1.0, think big and document everything!

Defining the MVP

MVP, or Minimum Viable Product, is a particularly loaded term. For our context we’ll consider MVP as the minimum feature list where you could possibly see yourself or a willing tester using your app to solve a real problem.

Keep this list as lean as possible. Avoid the trap of assuming things are must have. Ship something that is scary simple and let your earlier testers tell you what’s missing or what’s blocking them from starting to use your product day-to-day.

Start Drawing the User Experience

With a handful of required features and behaviors documented, start to draw our your app’s user interface. Use whatever tools help you get ideas out as fast as possible. At this stage you should be working at a very high level, very broad sketches of your app views and interface elements.

I usually start off with pencil and paper. Simple sketches help me experiment with ideas. Usually I’ll have a list of behaviors a view needs to accomplish and then work from there. Once I have an idea out of my head I then put restrictions on myself and redo it. For example, let’s say I’m building an email client and my first pass is a master-detail style layout. For my second pass I put a restriction that I can’t use that pattern, how else could I solve this problem. How do I solve this problem with just gestures? Just buttons? No table views? Do this a few times to allow your brain to unlock its creative juices.

I may eventually, start to transfer my pencil and paper drawings to a low-fidelity digital version. I’d still be dealing with black and while outlines at this time but there can be a digital advantage here, letting me copy and paste, doing a bunch of different small tweaks without redrawing the whole window. Balsamiq Mockups is one tool I really like for this, though I’m also trying to learn Sketch.

Getting Early Feedback

With a dozen or so UI drawings done, it’s a great time to start talking to some people and getting feedback. Ask your friends but also try to ask some people who are more neutral towards you. The problem with asking friends for feedback is that most want to please and have a hard time giving an honest critique.

Planning Your Work

One of the things I’ve learned about myself is that I do much better when I separate design time vs learning time vs development time.

  • Design Time: feature brainstorming, sketching out UI solutions.
  • Learning Time: figuring out how a technology or API works, researching the competition (for design/feature info or business info), talking to users.
  • Development Time: Executing a solid specification in code to build out a feature.

Balancing your time in these groupings is crucial to make sure you have an overall velocity for your project and don’t get stuck in learning mode full-time (or on the flip side, end up coding solutions that are not usable).

For planing work I use 2 week sprints and lean toward Pivotal Tracker these days, but I also like Trello. Ultimately, the simpler the tool the better. Don’t let the tools eat more time than they are saving you.

Ending a Sprint

I like sprints. I love ending sprints.

I feel like if done right sprints provide a good balance of focus and pressure on deliverables. I also like how even when working on a long and complex project you have these moments of retrospect, looking back at all you have accomplished in the most recent sprint. If feels good. It can be addicting.

Repeat

With luck you can get something to ship after a few sprints and, from that point on, it’s all about incremental improvement. Release, Measure, Learn, Repeat.


While far from a definitive collection I think this is a nice introduction to my own recommendations and thoughts for project kickoffs. If you want to read more, one book I really like on the matter is The Nature of Software Development. It’s short, with lots of fun sketches. It’s a quick read and the content is really solid. I share many of it’s core values.


Enjoying the site? Sign up for our newsletter.