0

I'm having a hard time distinguishing the purposes between:

  1. Feature List
  2. Product roadmap
  3. Release schedule
  4. Task management
  5. Project plan
  6. etc.

For my mobile app concept, I'm using trello and evernote to manage my ideas/tasks. I started shipping releases and the UI is getting more complex, etc. When I tried onboarding a friend to help with development, he was completely lost as to what was planning, work to do, bug priority, etc. I feel like I'm making this way harder than it needs to be, so I probably just missed a core PM concept somewhere. Any resources would be great! Thanks

1

he was completely lost as to what was planning, work to do, bug priority, etc.

Here is your key. What you've done makes sense to you, because most of it is probably in your head (you know what you want to work on next, you know what the "end state" looks like).

When you grow your team you're going to need to standardise some of these methods to get them out of your head and into a process. A few things you're going to want to do:

Product Vision

Put some statements together that indicate what you're trying to accomplish at a large scale. What is your product aiming to do? What problems will it solve?

Feature List

More specific than the Vision - what are the individual components of your Product? Eg for an online store features could be:

  • A shopping cart to add products
  • A storefront to view products
  • The ability to sign up and login
  • Automatic weekly emails to customers etc...

These features may translate well into cards on your Trello board (depending on the granularity of your cards/features)

This list will give your friend an understanding of the "pieces" of your puzzle that create your Product Vision when assembled.

Prioritisation

Your Trello board can be helpful for this. Make sure it is prioritised - cards of the highest priority at the top, the lowest at the bottom. This way your friend will know what to work on next.

Release Schedule

You're going to want to let your friend know (and plan for) when the next release will be. Which features are you aiming to put into which release? Is the release on a fixed date or is it dependent on when the features are finished? This is what will keep you and your friend aiming towards that short term goal together, knowing when the next big "milestone" is.

Remember that releases have overhead - to release you've got to be sure your code is well tested, that you haven't broken previous features, so knowing when the next release is helps you both plan your efforts.

Tools

It sounds like you're suffering from lack of process. Trello and Evernote are very free-flowing tools, they're very flexible. They will let you do what you want. That can be good, but when working with others it can become hard unless you're very good at defining and sticking to process.

You may want to look at a Project Management tool with a bit more structure to it than Trello, maybe something like Rally (https://www.rallydev.com/). There's added overhead to a tool like that, so again it may be worth trying to define your processes and seeing whether you can be disciplined enough to make them work in the tools you've got so far. Discipline is key!

So to recap, here's what should be on your TODO list:

  1. Create a Product Vision
  2. Create a Feature List
  3. Ensure you have a Prioritisation Process
  4. Set a Release Schedule and work out a Release Plan
  5. Find the right tools to help you manage the processes above

If you get these in front of your friend I think you'll find the shared vision/goals/plans/priorities make it much easier.

0

I would highly recommend looking in story mapping. It's a very simple, clean way to create a reference for the overall view of a software product, goals, releases, risks, etc.

  • Thanks for this tip. Do you have any suggested reading other than the top hits I'll find on Google? – kevando Dec 15 '15 at 23:36
  • "User Story Mapping" by Jeff Patton is a solid resource. Prior to reading that, I had applied mapping a few different ways (often "halfway" with only partial benefits) but I got a lot of good tips from that book that improved our use of mapping - doing subsequent passes while applying different viewpoints or "lenses", slicing it into goals, etc. There are a lot of variations on the approach out there, so definitely read up as much as you can and think about their benefits vs. your context. Good luck! – Jeff Lindsey Dec 17 '15 at 14:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.