What is Project Roadmapping?

Project roadmapping is the most valuable thing you can do for your project. It is the best way to figure out what you need to build (and what you don’t) before you get started. With Bixly, at the end of this process you get wireframes, fully defined user stories, a clear roadmap of what the next three months of development will look like, risk assessment, and peace of mind. This is a huge differentiator between working with Bixly and trying to hire developers or find freelancers.

The purpose of project roadmapping is to help our clients achieve success. We help validate their idea to the market. We go beyond timeline and budget, to help identify success criteria. We will research the necessary integrations, whether that’s a third-party database or even hardware integration, to confirm before we get started that these tools can work together well. We also do risk assessment on the project to identify as many potential pitfalls to the project as early as possible. As Cody states, project roadmapping “allows you to test your own business ideas before you go out and actually implement them.” It gives you the opportunity to validate the market and to see if what you want to build is actually feasible with the technology we have today.

What do you get at the end of project roadmapping?

You’re going to get a plan to get your MVP to market in about three months. We do that so we aren’t over-extending beyond budgets and also to be realistically plan for the future. A three month timeline is reasonable to plan for with little to no changes to the plan. Once you start planning years in advance, it becomes much more difficult to plan without inevitable changes. You also get wireframes, which are low-fidelity sketches to outline the user interface. These are great not only for providing you with a vision of what your app will look like, but also so you can share that vision with stockholders and potential users to get feedback. As Andrew says, “It’s very inexpensive to change things on paper. It’s much more time consuming and costly to change things in code.” Getting that early feedback is invaluable. Project roadmapping ultimately brings a lot of peace of mind.

Why did we start offering project roadmapping?

Because we really wanted to begin with the end in mind. By planning together, we can make sure there isn’t any miscommunication. Our clients know what they will have at the end of this project. Without project roadmapping, its easy to get into scenarios where the developer may misunderstand what the client is actually asking for. Project planning helps us to uncover those missed expectations so there’s no surprises at the end of the project.

How does with Bixly differ from working with a freelancer?

When working with a freelance developer, you will go through the process of vetting them, talking through you business idea and dispatching them to work on tasks. Ultimately if you’re working with a freelancer, that’s probably what their specialty is going to be. If you need someone to plan and vet your business idea, you may end up needing to hire someone else, who has that expertise. You may then need to hire another freelancer to do project management, if you’re not going to do it yourself. And then another freelancer to handle design. Ultimately what ends up happening, is you end up having to hire all these disparate people and diverse skillsets to effectively work as a contracting agency, with a huge amount of effort and time and communication overhead required of you.

By contrast, working with Bixly you have all of those facilities all in one place with a cohesive team that communicates well. Project roadmapping is included with the project overhead. It helps our team work more effectively on your project and it provides accountability for what you will get at the end of the project.

How to Do It Yourself

If you want to dive into the project roadmapping process yourself, there are a few questions that you should explore.

1. What is my success criteria?
2. What is the technology experience of my typical user?
3. What are the risks that could potentially derail my project?
4. What needs to be in my MVP and what can be saved for later?

If you feel like you would like to leverage our expertise and advice in your project roadmapping process, the first consultation is free! Book an appointment now to get started.

Episode Transcript:

Alexandra:

Hi, everyone. Welcome back to another episode of Bixly Tech Tuesday. My name is Alexandra, and today you’re going to be joined by Andrew and Cody as they talk about project roadmapping. I’m not overstating this when I say that this was probably one of the best things that you can do for your app to set it off on the right path, to make sure that you’re saving time and money. Let’s learn more about what they have to say.

Cody:

So, Andrew, in the world of project management, a big part of making sure your project is going to hit its goals is a concept called project roadmapping. I understand you’re a project manager. Would you care to talk to the crowd about that?

Andrew:

Project roadmapping is a service and we started offering at Bixly to really help ensure that our clients’ new projects are going to be a success. We do things like help them validate their idea to the market to make sure it’s a good fit, to make sure that what they’re putting out there is going to genuinely address their customer’s needs. We go beyond things like just what is the timeframe, what is your budget to actually helping you identify: what does winning look like? What is the success criteria?

Andrew:

We also do things like look into different integrations. If your system needs to interact with a CRM or some kind of third-party database, we can help you look at things like: how is that going to work? Make sure if you’re doing any sort of hardware integration, we can help validate that. We also do things like helping you identify risks that you might be running into, the potential pain points where things might fail or stall, maybe requirements that are below the surface that aren’t immediately obvious.

Andrew:

Ultimately, what project roadmapping is is helping you identify: what does winning look like? What is your roadmap to success? So that as we’re planning out this product, we’re thinking about things more than just what’s your budget, and what’s your timeframe? But actually, how can this be successful, and ultimately improve the quality of your life and for your customers.

Cody:

Another aspect of project roadmapping is that it helps you test your own business ideas before you actually go out and implement them. The idea of kind of sanity checking, and validating your own business goals and ideas from just a simple marketplace validation to make sure that there’s a customer base to double checking that the actual flow and product idea is feasible within the current technology that exists. That’s a big part of being able to do project roadmapping. To basically test your project and your business in vitro before you test it in vivo, so to speak, in a scientific sense.

Cody:

What happens when a project actually goes through the roadmapping process? What does a client get out of that when they finish up with all their planning?

Andrew:

When you get to the end of the project roadmapping phase, you’re going to end up with a few things. One of the things you’re going to get when you get to the end of the roadmapping process is a plan to get your product, or your MVP, to market in about three months. And we do that so that we’re not overreaching or overextending beyond budget. But we’re really defining what are the important criteria that’s going to bring the most value to your customers in that period of time.

Andrew:

You get a plan, again, to get you to market in about three months. You’re going to get wireframes, which are low fidelity sketches essentially that show what the user interface is going to be like. And this is really important, because it allows your stakeholders and your users to envision what they’re going to get, how they’re going to interact with the software without actually taking all the time and expense of building the whole thing. It’s very inexpensive. It changes things on paper. Much more time-consuming and costly to change them in code.

Cody:

Yeah, I agree. That’s well said. A big part of that, just to reiterate, is basically the idea of identifying issues before you’ve effectively built them. As soon as you start building any sort of software without a plan and you end up kind of canyoning yourself up with all this idea, and then you find out midway through that you have to change a lot of underlying fundamentals because something didn’t work out. That becomes extremely expensive. And to, kind of, mitigate that scenario, the best way to do that is through project roadmapping.

Andrew:

Project roadmapping also serves to bring just a lot of peace of mind. You now have a plan or a roadmap for the extent of the project. You know what about the next three months is going to look like. You have a really good idea what to budget, what your timeframe is, and also just a firm fixed quote, so you know exactly what this is going to cost and how you can plan for it.

Cody:

In the world of tech consultancy, there’s a lot of people who’ve kind of done consulting and dealt with programmers and all of that sort. And a lot of the time, there isn’t really a whole lot of planning that goes into software development before they get started. They just kind of go. Why have we started offering project roadmapping, and how does that really benefit the customer in the long run?

Andrew:

So, we started offering product roadmapping because we really wanted to begin with the end in mind. We wanted our clients to be very purposeful about identifying what their success criteria is. Also, ultimately just what are they going to have at the end of this process? We want to make sure there’s not any miscommunications or missed expectations. It’s really just about defining a map of what we’re going to be doing in these first three months of the project.

Andrew:

How does working with Bixly and doing project roadmapping contrast to something like if you were to hire a freelancer off Upwork?

Cody:

For sure. I think a big part of that would be to outline the usual process of working with a freelancer. You go and vet them. You talk about your business idea, and then a lot of the time you simply dispatch them to work on the project itself. Ultimately if you’re hiring a programmer freelancer, that’s probably what their specialty is going to be. And if you need someone who can help you plan and vet your business ideas … sure. You can spend their time doing that, but chances are that’s just not their specialty. Then you’re looking at the situation where you got to hire another freelancer to do that job, and then you have to probably hire another freelancer to do project management if you’re not going to be doing it yourself.

Cody:

And ultimately what ends up happening is you’re paying all these several separate large bills for a bunch of disparate people to effectively work as a contracting agency with probably a lot of communication overhead in the meantime, which you will have to facilitate. At Bixly, we have all of those facilities built in place, and all of us are very cohesive with how we actually talk to each other. Part of the project roadmapping process is that it’s pretty much included with the project overhead and it’s somewhat expected.

Cody:

It helps all of our staff actually get their job done quicker, and it helps there be accountability for certain features if something comes out weird later on. Which I’ll guarantee you if you have a freelancer, if something ends up different than you specified, they’re going to point to the roadmap document and be like, “Well, there’s a black hole here. I interpreted it this way, and you ended up getting it the way I thought. But as it turns out, that was different than what you expected.” So, you get to pay for it and do it again. That’s a big difference between a freelancing situation and Bixly is that ultimately we have the cohesive nature of being able to plan, and execute, and have those roadmaps, and have project management, and have a design team, and have software engineers working with everyone all under the same roof, and all being able to communicate as effective as possible.

Andrew:

What I’m hearing you saying is there’s a certain advantage to working with a team because of the cohesiveness. When you’re working with a freelancer, the reality is they’re going to have a certain skill set and set of tools that they work with. Those are obviously going to be things you recommend because they do them well. Now, there’s going to be a gap at some point, and you’re going to be needing to kind of build your own team or sort of hodgepodge together a variety of freelancers, which are not accountable to one another, don’t work with each other communicate most likely. And so you’re kind of put into the role of project manager or team builder.

Cody:

Yeah. Yeah. Basically the difference is: you can either hire all these freelancers to effectively create a software consultancy yourself from the ground up, and pay for all the overhead, and deal with all the time and commitment that it takes to get a bunch of disparate people to work together. Or you can hire someone like Bixly or Bixly themselves.

Andrew:

And why wouldn’t you just find a freelancer that can do everything?

Cody:

They don’t exist.

Cody:

Let’s say someone wanted to do project mapping on their own. Project roadmapping, I should say. What would be the questions they would ask or answer of themselves to accomplish those goals?

Andrew:

I would start with, again, what does success look like for your project? What, ultimately, are the metrics that you’re going to use to determine whether it was a successful project? Whether you won or not? Another thing you need to do is look at your user demographics and just see what is their technology experience. If you’re building something with a user interface, is this going to be power users that are going to be using this or does it need to be very dummy-proof? You also need to analyze the risks, the things that could potentially derail your project.

Andrew:

For example, if there is an easy interface with some third-party API, what if it’s not straightforward? What if it’s buggy? Or what if the hardware you’re doing has a pretty poorly designed software development kit? Or maybe you’ve decided that your tech stack is going to be in Python. Do they have a software development kit for that? These are the things that we help you look at ahead of time or look further down the road, that way you don’t engineer yourself into a hole.

Andrew:

I’ve had people before who have gone off on their own projects, and let’s say they’re doing something all around Android. And then they want to integrate a particular piece of hardware with an Android tablet only to find out that that hardware has no native software development kit for Android. And now they’re like, “Well, we’ve done all this work. We’ve done all this engineering. How do we make it work?” And the answer is either you can’t, or you have to sink in a bunch of time and money to make this work. Again, roadmapping is really just about kind of looking down the path and identifying what could go wrong, and what’s the best path to take.

Alexandra:

Thank you for joining us for this episode of Bixly Tech Tuesday on project roadmapping. I hope you enjoyed that conversation. If you’re ready to get started on your app, don’t hesitate to reach out to us. Head to our website, bixly.com, and hit that free consultation button. That’s the best way to get started. Until next time. This has been an episode of Bixly Tech Tuesday.