Product Development Roadmap – Everything You Need to Execute

If you’re living under a rock as a founder, maybe you didn’t know that – Product Development is half the battle before you see any success.

The other half is fulfilling your founder duties – which I will tackle in another article.

For right now, let’s talk on what you need to execute on your vision of your product. Chances are, if you’re a founder, you handle Product Development in 1 of 3 common ways.

1 – Hire an agency to handle the software development part of the process.
2- Hire resources directly from a resource augmentation service or freelance platforms.
3 – Be tech savvy enough to build the whole damn thing yourself (usually with a technical co-founder).

Now if you are number 3 – perhaps this won’t be of much help to you. But if you are 1 and 2, tell me if you’ve experienced this before:

Pain Points of Hiring A Product Development Agency

– They tend to dive head first into development without discovery or a plan. Everything happens on a ‘as needed’ basis.
– They make it very challenging for you to change directions. They will agree to a very basic build plan with no drilling down of the deliverables.
– They will always delay on deliverables in the long term (since usually there isn’t a plan to follow).
– Their documentation tends to be quite poor from the get go because most agencies won’t invest in process building.
– They aren’t transparent on who is working on your project. You will never get to see the whole team.
– Every disturbance in the air as ‘additional cost’ associated with it. Change requests are fair, but charging every request is not.

Pain Points of Hiring freelance talent directly

– Finding and sourcing talent in the digital age is just a mess. You will spend more time looking for the ‘right’ talent than getting to work.
– Here’s what you needed, a team to manage on top of the gazillion things you were responsible for – good luck!
– Freelancers are humans (I know I know, hot take) and they will have issues working full time. You will be left hanging mid way when something happens.
– Paying people around the globe isn’t as easy as you thought and now you have to become a mini accountant as well.
– Communication could be better – everyone ‘speaks’ English, seldom understanding the meaning behind the intent of words.
– Getting your whole team on the same page will be a challenge as you need to ensure consistency of work being done between various people with various technical (and cultural) backgrounds.

Now of course, this isn’t the story with ‘every’ Agency and Freelancer run Product Development. But these issues are commonly faced by many startup founders.

I myself have worked as a freelancer and proudly rep’d my 100% Job success score, Top Rated Plus badge and long term clients success stories. But there’s a reason only the top 7% get that honor. 

If you’re like – Hey Saqib, I have an excellent experience with “Insert XYZ Agency”/I have great experience working with “Insert XYZ Freelancers”. Then more power to you. 

But if you’re nodding your head in regret as you read the points above, here is the missing piece.

You need a Product Development plan before you dive head first into execution.

See, much like how Product Management and Product Discovery is all about ‘what’ to build. Market Research is all about ‘who’ to build a product for. 

A solid Product Development plan is the ‘how’ behind executing on your Product vision.

Whether you are highly confident in the team you are working with or lost on how to execute on your idea, a solid plan can help you focus your efforts on being a founder, not a project manager.

Having done software development documentation for over 100 projects, I know what matters most when it comes to having a Product Development plan for most startups.

As always with my services, the philosophy is simple, it’s all that ‘you need’ and nothing ‘that’s extra’. Hence the process always is to get on a call first, then decide on what you actually need.

---

Breakdown of a Product Development plan for Early Stage Startups

So what makes my plan different from what you just googled?

First of all, it has developed over 100+ projects of experience. Not just some SEO optimized spammy article. But what is most important for you as a founder is the fact that I go over what not many services do – how to build a team around the plan you just worked so hard to make.

Lastly, with this plan, you can go to any agency or team – and get your product built out. 

(Fun tangent, if you’re an Agency owner or a freelancer reading this, then click here to learn how you can get better at Documentation)

Here is what is typically involved in building out a development plan for your startup:

• Epics Definition – defining your product in building blocks
• User Flows – laying out the most used flows for your users
• Information Architecture – a map of everything, linked together
• Feature Prioritization – avoiding being a feature factory and actually launching
• Team Requirements – what kind of team you should have at the minimum

Now this isn’t a line in concrete, but these aspects cover everything you didn’t have before, and now you will. Note that all of these aspects are developed in parallel as they are interlinked.

So now let’s get into what each of these aspects mean for you.

Defining Epics/Modules in the Product Development Plan

Here’s what an Epic means

“An agile epic is a body of work that can be broken down into specific tasks (called user stories) based on the needs/requests of customers or end-users. Epics are an important practice for agile and DevOps teams. When adopting agile and DevOps, an epic serves to manage tasks.”
– Source

And that is all the Agile project management you need. We take what’s good about Agile, and ignore the rest.

Epics are an excellent way to break down your product into executable little chunks.

This will give you the high level vision of the ‘module’ that needs to be built out for your first version of the Product. Some call it MVP, some call it never ending phase 1, and some call it the Alpha. What you need to know is the breakdown of everything all the way from authentication to settings on your product.

Typically we will start out defining epics for platforms.

Usually every App or Web App will have 2 platforms. A User facing version, and then an Admin facing version. 

If you have multiple types of users, or multiple levels of Admins – we will divide it up further.

The rules for defining an Epic are varying across the board. But typically speaking the best way to define them in my opinion are to limit the functionality to one flow.

Epics are the building blocks of your Product Development roadmap. Hence they need to cover everything that we have set out to execute. You need someone really experienced to come in and help you set up the modules for your product. End result will be something that looks along the lines of:

– Source

Now as you can see in the image above, once the Epics are ready, you need to break them down further into stories and tasks. And that is a bit too much at this stage for your needs. Hence we’re gonna skip over that to revisit once our team is onboarded.

Knowing what is necessary VS what is excessive is the secret behind efficient execution.

Documenting User Flows for your Product Development Roadmap

So here’s why I suggested skipping over defining stories and tasks at this stage. In my experience, instead having document user experience flows are a much better way to approach execution at the early stages.

Something like:

I like to document 3 things for User Flows:

1 – What will be the intention behind the whole flow. Placing an order, scheduling a call, sending a message, etc
2 – What will be the actions required to be taken for the flow. Tapping on a contact, adding items to cart, picking a time slot, etc
3 – Expected outcome of the user flow. A order is placed, a meeting was scheduled, an item was purchased, etc

When you view each flow in the breakdown of intent, action, and outcome – it makes it really easy to setup the associated Epics to build for in relation to the various Product features.

For more complex products, we can always map the user flows further with a technique known as User Story Mapping

Which is: User story mapping is a visual exercise that helps product managers and development teams define the work that will create the most delightful user experience. It is used to improve your understanding of your customers and to prioritize work. Software leader Jeff Patton is often credited with having developed and shared extensive knowledge around user story mapping.

– Source

Again, we need to be really careful with the facts of life. Remember, only have what is necessary, not excessory.

Information Architecture for your Product

We have the Epics, and we have the flows – time to link them together.

The information architecture (a fancy sitemap) is the visual representation of how everything is tied together.

This helps identify and fill any gaps in the Product and also give you an overview of what needs to be built out – in a visual manner. Add some colors, and you can really get a good view of what your team will be working on in order of priority.

The key aspect behind a good Information Architecture is having a navigation flow that just makes sense.

You don’t want 20 clicks between an intent and an outcome.
You don’t want 6 screens before relevant information is seen by a user.
And you definitely don’t want modules just chilling in the air like they don’t care – everything MUST be linked with purpose.

Lastly, menus. Yes, menus.

Menus are the go to place where most of the interaction happens for a lot of products. Designing a menu that is focused around user experience is harder than one may think. 

The IA needs to tie effective navigation with a hub(menu) that is intuitive for the user. As long as you keep the idea of intent, action, and outcome in mind – you will have a resulting IA that just works.

Feature Prioritization – Ranking what matters

The biggest mistake a lot of startups make is becoming a feature factory at a very early stage. It can work ‘some’times but will lead to failure mostly. Features are what make your product usable, but they should never be built ‘just because’.

I cover more on this over here, as to why following trends can lead to having no market fit in the long run.

Putting it simply, the features you prioritize should

Fix the disease, not the symptoms

In the Product world, frameworks exist a dime a dozen for feature prioritization. And all work depending on what the expected outcome is.

But as someone who likes to keep things simple and straightforward – I prefer the following 2:

Kano Model Method of Feature Prioritization

The Kano model methodology operates on the premise that customer needs can be segmented into three distinct categories: basic, performance, and delight.

Basic needs are fundamental for the product’s basic functionality.
Performance-oriented needs enhance the product’s functionality and efficiency.
Delightful needs enhance user experience by adding enjoyment to product usage.

MoSCoW Framework

The MoSCoW Framework is a structured approach that comprises four prioritization levels: MUST, SHOULD, COULD, and WON’T.

MUST features are of high importance and require immediate implementation.
SHOULD features are significant but can be deferred for later implementation.
COULD features are of lesser importance but can be considered if resources allow.
WON’T features are deemed unimportant and should not be pursued for implementation.

When we combine these two, we get a simple yet effective way of prioritizing what matters the most to you. We are an early stage startup here, and we can’t afford to waste effort. Ruthless prioritization can be painful, but sometimes necessary to align the product vision with the execution.

---

---

The Team Required for Development Execution

This is where we will get a bit of help from our friend Agile again. So a typical dev scrum team would consist of the following:

• Product Owner
• Scrum Master
• Devs
• QA
• Business Analyst
• Solutions Architect

What we need for our startup will have a similar setup with few differences. 

For starters, we need designers. UI and UX designers are actually two different things, if you can find one skilled at both, kudos – if not, then we need two.

The other thing that will be different is the role of PO/Scrum Master/Project Manager. As an Early Stage startup you don’t need multiple people carrying out this workload. A lot of it can be shared between the QA and Tech Lead of the team. While a general purpose Project Manager can handle the role of Product Owner along other needs.

In my experience, this is a must have setup for your initial team focused around execution:

• Project Manager/Product Owner
  • Will be responsible for working on execution of design and development with the relevant teams. Everything related to the ‘How to build’ behind the product. This is a rotating role and can be reassigned to the QA person later in the project.
• QA/Project Manager
  • To start out with the QA person will be responsible for manual functional testing of everything being built out. Later on the QA person can take on PO responsibilities as testing needs lessen over time.
• Full Stack Dev
  • All purpose Devs that will be working on the frontend and backend of the application. These will be a mix of talent but the basic requirements will be that they must have 3+ years of experience + portfolio in the tech stack we are using.
• Senior Dev with DevOps experience
  • A tech lead position for managing all technical aspects of the development through and through. The person will also need intermediate understanding of DevOps and Solution Architecture setup. The person will be responsible for doing code reviews, making sure dev is happening in an efficient manner, and helping Devs with problem solving. 
• UX Designer
  • Since we are building a complex Web App, we need a dedicated UX person to come in time to time and advise on the best UX practices for the project. We will try to maintain the visual identity of the project as much as possible but will have to fine tune certain components as per tech limitations.
• UI Designer
  • This person will be responsible for all visual assets and visual design for the main parts of the project. We can also utilize the UI designer for various work related to business design tasks.
• Tools and Tech
  • This will be all the resources the team requires to function effectively, including but not limited to
    • A project management tool (such as Notion or Basecamp)
    • A communication tool (such as Slack)
    • Hosting and Domain Solutions
    • Security solutions such as Cloudflare
    • API access for integrations with third party services such as GPT, Performance, Analytics, etc

Again, the thing to keep in mind is that we need people who go wide, not deep – at this stage. And as we grow, we hire specialists in their respective domains.

I have seen founders getting distracted and going out hiring Dev Ops specialists and Cyber Sec Analysts when there isn’t even a product ready yet.

If you do feel the need for experts at any stage, leverage them on a fractional or on as needed basis. Otherwise stick to the breakdown above and budget accordingly.

And on the topic of budgeting, here is how you can do a very simple one:

Resource Designation	Commitment Type	Duration (months)	No’ Required	Average Monthly Cost per resource (in USD)	Total Cost per resource(in USD)
Product Owner/Scrum Master	Fulltime to Part Time	6	1	Add your budget for each resource.	Multiple by duration and quantity of resources.
QA and Project Management	Part Time to Full Time	4	1
Full Stack Web Developers	Fulltime	6	3
Senior/Tech Lead /w DevOps	Fulltime	6	1
UX Designer	Fractional	3	1
UI Designer	Part Time	6	1
Tools and Tech Cost	N/A	6	1
Grand Totals				$0.00	$0.00
Fulltime	Dedicated person fully engaged during all work hours.
Fractional	As needed, person only engaged when required for a specific workload.
Part Time	Part time person engaged on a daily basis but with limited work load.

If you’re building a mobile App, switch out the Full Stack Devs for dedicated Frontend and Backend Devs depending on the tech stack.

What Next?

I specialize in providing services to founders to fill in the gaps. The gaps they face in their Product till they reach PMF.

I am a strong believer that most startups do not need dedicated Product Managers in the early stages BUT they do need Product help.

What I have laid out here is an excellent example of where you can get such help as a startup founder. 

With knowledge of all your modules required to be built, clarity on feature prioritization, visualization of the information architecture, documentation of the user flows, and needs laid out in terms of resources – you are now ready to execute with a solid plan.

With or without my help – I wish you the best.

---