So at MobDesign, I don't take a client on without doing a road mapping session first. And what is a road mapping session you will ask? Well simply enough a road mapping session allows me and the client to create a path to get from where the client is today to where the client wants to be tomorrow.
Those sessions usually go from a few hours to a day or two depending on the size of the project. Below are the various subject we'll touch on during those sessions.
Your business goals
I want to know what it is you are trying to achieve with your project. Is your goal to create an MVP to test out a market? Create a v1 for idea that is already proven, but needs to reach more users? Create an internal app that will help your employees be more efficient? Create a marketing application to showcase your products?
Why do I care? After all, you came to me with an idea for an application, why won't I just start coding it today?
Well, there are lots of ways to create an iPhone application. For an MVP, I can create an application that won't handle all the edge cases, so you save on development cost while you explore whether your app concept is even worthwhile.
For a V1 project, there are lots of consideration to have around stability, maintainability and monitoring to get a product that you can build on easily in the future and that won't break in front of your user every 5 minutes.
So the conversation for the rest of the project will be different based on your business goals.
Your target audience
I remember when I was at Microsoft, a couple of weeks after joining the office.com team, I asked: "Who are we designing this feature for?". My boss responded: "Everyone".
This is about the worst response you can have, even for a website that sees millions of visitors. There is always a target population you are designing for. Not every one wants to use Instagram, Twitter or your baby sitter finding app.
Same for your app idea, knowing who you design it for will allow you and me to prioritize your user story, allow us to design the app for the population you are targeting.
Your user stories
This is where a lot of people get confused. Usually a client comes to me with list of features, and I ask them about user stories. What are user stories anyway?
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a <type of user>, I want <some goal> so that <some reason>.
User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
So a user story is really just thinking about what the users want to do to. From those you then define what features are needed to achieve this goal. You'd be surprise about how many ways you can solve the users' problem. And some are vastly more expensive to create than others.
Some people don't like to talk about this. Their fear is that if they tell me their budget, I will quote them back this number. This is not my intent. To explain why this is an important topic, I like to use the car analogy. If you went to a car salesman and told him: "I want a car". He'd able to offer you a small Hyundai with no frills or a fully loaded Porsche SUV. And you'd still have lots of choices in between with varying level of features, quality and finish. Knowing your budget allows him and you to narrow your selection to the car you can afford. You can still buy a car that is less than your budget though.
Same for apps. If you already have a budget in mind and a set of user story, this will allow me to give you options as to how to reach your business goals within your budget. Those might include:
- Shortening the list of user stories
- Lowering the quality of the app
- Increasing the budget
- Cutting the project
Quality of the app
Apps are not all created equal. Some will look like a basic application other are highly polished. Another quality axis to measure quality by is how easy it is to maintain, add features to, fix bugs. You can save some money and create an app that will crash all the time and be expensive to maintain and build on or invest in the future of the app and build a solid foundation to build on.
This conversation is heavily influenced by your business goal and your budget for obvious reasons.
Third party services
Very rarely will an app not require some kind of third party services.
- Technical third party services to help learn about issue in your app
- Analytics services understand your users' usage of the app
- Potential servers
- Service like intercom to easily talk with your users directly from within the app
All those have benefit and cost associated. So a careful conversation can help you make the best decision based on your business goals and budget.
How often do you want to release? In the agile world a good project should be able to be released at a regular interval, at the end of each sprint. So about every two weeks. Is that what you want?
Do you want me to take care of pushing the application to the App Store or is it something that you want to do? What kind of synchronisation with your marketing team will be needed?
Shipping an app is only the first step. Once the application is out, the second part of the journey starts. Data from your analytics service, crash reporting service and feedback system start to roll in. And yes, bugs get discovered. Would you like me to keep an eye on those or will you take care of those.
Time should be budgeted to fix bugs after release, because no matter what people say, shipping a bug free app is not possible within most companies budget.
Planning for maintenance is a good thing, because again, this will affect your budget.
This is never the fun part, but it has to be approached. The idea is to identify all the risks we can think of about this project. Do you collect PII? There is a risk associated with that, and plans need to be made to ensure this data is kept secure? What happens if the database is breached?
Another more recent example is Parse.com. A lot of project got built on that platform, and eventually it was announced that it would shut down. That is a considerable risk to your project. It should be discussed, even if very briefly.
Why pay for it?
This has benefit for both parties. From your perspective, this gives you the opportunity to work with me for a relatively small cost, see how I work, see if we get along, see if I actually deliver on my promisses before you commit to a much larger engagement.
Secondly, you'll get a report at the end that recap all those conversations, listing all the tasks for the project with time estimate, recommendation for various services to use based on what you told me. You can take that document and ask someone else to implement the project if you'd like.
Third advantage is that you will get a much better estimate. When other companies do unpaid estimate, they tend to rush through it because they are not paid. Their goal is to get it back to you as fast a possible. If the estimates are not accurate, then they'll either ask for more money or cut corners. You'll end up with an app that was not what you expected or the agency will end up loosing its shirt.
From my perspective, the benefits are similar, I can learn more about you, how you work and decide if I work well with you or not. This help build trust between you and me.
Since I'm paid, I can also take the time needed to understand the project, research what needs to be researched and give you realistic estimate. This brings me peace of mind that I'll be able to deliver what you expect.
Do you like the idea of road mapping? Reach out and let me know.