Ask HN: How to properly manage a product roadmap? Hi. I'm the PM for a small fintech startup and the business team is constantly changing priorities based on new client requests, so the tech team cannot cope with all the new features and these end up suffering continuous delays. Do you let new customers drive your product roadmap, or just decide your own roadmap and stick with it? Which approach works best in order to gain more product velocity? |
For the first category you need to look at the whole picture, as they often affect many parts of the system, and there need to be a coherent strategy/plan.
For the second category, just go ahead and implement any such feature if have the time to do so. But don't forget that all new features have a future cost, as users would miss those quality of life features if you remove them in future versions.
honestly the best tool i've ever used for this. and phenomenal software in general.
But look-- if you're letting other people come in and define your vision for you... well, you're no longer doing management-- you're following someone else's vision and they're managing.
You own the product vision. You choose what to incorporate.
I'd ask google so you can find some books and in depth knowledge. A comment or two in a forum is decent for tips, but if you want knowledge, I'd go seek it where it is developed in depth: books.
It's hard to give generic advice not knowing more about the context but here's one way that I've found useful and successfully executed. Bucket your roadmap into 3 rough buckets - delight features (no one has specifically asked for but that deliver high value), customer requests (obvious), and your/company's product vision (not something you just concocted but based on real data and validation).
The % of your roadmap and sprint allocated to each bucket depends on your specific business, current situation, and startup/product stage.
Don't let customers hijack your roadmap. Talk to them, listen to their needs, understand the requirements coming from the business team, evaluate the severity and sensitivity, and ultimately prioritize yourself. There are times (sprints/months) where > 60% of my roadmap has been customer-driven and times when only a third of it are customer requests.
Both, but you need to learn how to listen and translate customer wishes into the actual jobs to be done. "I want feature x" from customer A, and "I want feature Y" from customer B might be related to the same context and underlying problem, so it's best if you create a level of abstraction to sort customer wishes into. How the actual feature works and how it looks like should be your core competency, not the customers imo.
GIST is as close to scientific approach as we have right now.
RICE model might help as well [2]
However, being 100% honest, I tried all the models above and they did not stick to me. I'm playing Product Manager role for 16 years already and rely on customers feedback + intuition. When you have deep experience in the domain, you internalize many models and your neural network in the brain quite often just makes the right decisions. Don't decide quickly though, rely on your "slow" subsystem, decide as late as possible (and collect evidence).
Another trivial observation is that customers almost always ask you about some kind of solution. They rarely provide real problems. PM job is to dig into problems as deep as possible and then find a solution. In many cases solution is completely different from what customers asked. In some cases problem can be solved without new features.
[1] https://medium.com/@itamargilad/why-i-stopped-using-product-...
[2] https://www.intercom.com/blog/rice-simple-prioritization-for...
You need vision to gain a credible and influencal seat in front of management and customers, and hear from them. And not just saying yes to the last one who spoke.
You need passion to cope with all the crap (difficulties, management, engineers, customers, nay-sayers, finding ressources, etc).
And you need to be realistic and pragmatic to make something happen, even if not perfect/ideal. Maye next round.
https://threader.app/thread/1249039638829793280
(He also admits he doesn't knwo any Great PM who has all of the 30 traits and does all those actions, all of the time.)
SAFe is designed for larger companies, so you have to learn enough about it to understand where you can trim the fat. The big applications to your issue come from 2 places.
1. Lean Portfolio Management 2. Program Increments
LPM is a process of setting priorities by using real numbers where possible and best guesses otherwise. The result is a process that tries to measure value and urgency against your development capacity. Small things with high value float to the top. Big things with low value drift to the bottom and don’t bog down your team.
The Program Increment (PI) is an intense process that lets your dev team put out a plan for the next 8-12 weeks and gets the business to agree to it. Aside from getting everyone to agree to the current plan, it changes future business requests to “be prioritized for the next increment” which happens via the LPM process.
The PI plan still adapts to new feedback and can change, but those changes come with “if we do this, we can’t do that...is that acceptable?” Time for small changed and some variability is built in, so those conversations only happen for something major.
We use Canny (https://canny.io/) for feedback tracking. It helps us with:
1. Transparency with our customers. On the support side, we can show that we're tracking their requests, and where they fit into our existing roadmap.
2. Less stressful development cycle. I'm still completing some work in our backlog, but after switching to Canny, it's much more clear what the next features will be.
Also, here's our public Canny board which lists our feature requests & roadmap: https://cozycal.canny.io/
- you think your customers need
- your customers want (ask them!)
- which offer the highest return on invest
- your product needs when being compared with your competitors
When you have answered those questions, you should have a good feeling about which features you want to implement first. Next, ask the devs how your priorities match up with the development of the application and how much time it would take to build them. Some features might technically depend on each other.
Edit: Btw. changing priorities is okay, as long as nobody has started to work on a feature. As soon as the implementation started you better finish it. Make sure your business team commits to the things you start implementing and get the commitment from the dev team to finish things in time.
This is more on the engineering side, but if you can shorten the idea to client feedback cycle, then it's much easier to deal with all those requests.
It's also much easier to tell the business team "let's work on the what's necessary to get feedback on this feature (which probably mean not even an MVP) and we'll get result by the end of the month" than "I'm sorry, your feature has been deemed priority 12, we expect it to be complete in 6 months to 1 year, provided priorities do not change (they will)".
Once you get this feedback, then it's much easier to quantify things.
If it is decided that business us responsible, utilize a single backlog that the business can see and let them fight over the prioritization with defined practices.
Depending on the size of the company and overall development model I might use some framework (or pick suitable parts) like Less or SaFE to kickstart the new development process and then utilize larger scale retros to optimize the workflow continuously but in a structured manner.
Every feature request from the business and customers goes on the roadmap, along with any features engineering needs like supporting infrastructure, and there are regular meetings to make sure the list is always in priority order.
We've found having everyone looking at the same roadmap greatly reduces tensions. Instead of arguing over badly-remembered, vague requests, we work together to strategize the best approach. It's actually fun.
- Never promise a feature immediately when receiving a feature request. Say "Thank you for the feedback, we'll discuss this with the development team and get back to you if there's any news regarding this" (tag the user, so you can actually do so)
- Never choose to develop a feature until you've gotten at least three separate requests for it. This will help you not over-adapt to random noise, and make sure the product stays relevant to a majority of users.
- Never promise a timeline if you choose to promise a feature. Keep stress levels manageable for you and your dev team.
- If you have something 'up next' on the roadmap already, you may choose to share the estimate with the inquirer - but favor not doing so, and underline that it's an estimate not a promise if you do. Estimates also become much more reliable if random stuff doesn't get to jump to the top of the priority list all the time. Your roadmap is a priority queue, not a stack
- Consider thinking of it as two priority lists. One is for smaller feature requests and improvements, the other for larger projects and system/business needs (e.g. refactoring, features to target new demographics rather than existing users). Not progressing on either list is frustrating for everyone, so think of yourself as a scheduler trying to guarantee progress on both threads. For example you could have a rhythm where it's ~1 month of work on one or two big projects (until completed), then ~1 week of work on smaller feature requests and polish, then repeat. This way you batch up many smaller tasks so you don't incur the cost of context switching for your dev team while they are working on a bigger feature (which typically require deep concentration over many days), you don't block major projects, but you also get to be relatively responsive to customer requests.
- Remember that things take time. Your job as a product manager isn't to cater to every user's every need immediately, it is to plot a path through an endless and evolving roadmap in order to 1) Keep the business alive and prospering 2) Keep the development team productive and sane 3) Make customers happy. In that order
You need to know how much something is being used before you decide what to improve; so you need to collect usage metrics on everything.
I would also suggest getting quick and dirty Proof of Concepts/MVPs out there for people to use and validate. The very hard thing about MVPs is getting customers to realize that it is an MVP and it is incomplete and not "real". The value is that you can start to see usage information without a huge investment.
I really don't appreciate when other PMs come to me with a 1 year roadmap. Who knows how many thing we will not do, or change or pivot based always on the data we're getting? That's why I preffer better planned things (docs, teamwork) than a document with a nice unrealistic roadmap.
I think there's a way of tying these things together that reveals value and costs that can remain hidden. if you want an advance look at the manuscript, let me know.
It's definitely not for everybody, but maybe your fintech colleagues would find it interesting. it might prompt them to value what they learned along the way as well as the cost of changing course.
A roadmap isn’t concrete. You haven’t mentioned if you use agile methodologies or not, but sprints can buy some breathing time and deliver progress.
Once a feature request made sense to the product to add universally, if it wasn’t too disruptive, and depending on the feature, I might let clients vote with extra dollars to move it up the backlog.
Sometimes, a feature was requested by enough clients that hey might even split the bill on a extra body to get it done.
Before you can make a roadmap, you need a sense of direction.
Maybe you need to zoom out a bit. What do you offer? To whom? Why? Why them? What do you not offer? Why not?
Can you get those answers without asking your engineers to constantly build shit that they'll need to throw away?
Can you collect information cheaply? Can you ask your bizdev people to get answers to questions that will help you? What is the cheapest way to learn?
The more you build, the more you'll have to support.
Written meeting notes should be disseminated, and then corrected and augmented so that:
- Those who weren't there get an idea of what was actually said (we have meeting minutes in version control and anyone in the company can pull them and know exactly what I discussed in X town at which hour with whom)
- Those who were there realize they didn't hear/understand the same thing or plug holes. One catches what another has missed.
- Track rationale and decisions: All development through issue tracker. Avoid the "why was that feature added/removed two months ago again and now it's to be removed/included?" and not knowing why.
This should bring everyone to the same "initial conditions". If you don't do that, it's telephone game and you get a human-centipede like result.
Include form to request a feature in the product itself. Directly from the users so there's no distortion. Everyone should get that issue.
Also, if there's no product there is no business, which makes me wonder why the tech side is taking the backseat in a fintech startup. Fintech is like an airplane: you take a bus, you add wings, and you have an airbus that can travel faster and farther. Remove the tech, and it's just finance.
Add monitoring and analytics. We're working on that ourselves after putting out a lot of fires that looked the same.
Second: customers drive product roadmap in terms of raw data. Whenever users or customers ask something or raise an issue, ask yourself what is the underlying issue and what are they really trying to do. "Job to be done". Drill vs hole. Customers complaining is similar to patients complaining: they'll tell you about symptoms and then want you to fix those symptoms and they'll propose solutions and features. You gently take notes, and then dig deeper.
The analogy I use is that customers will ask for a robot with IoT and blockchain support that automatically integrates with Amazon API and orders mops, tracks the item, and has AI and image segmentation and recognizes Amazon drone, and receives the mops and automatically loads them. Because AI, blockchain, and IoT. Yes, it's not a sentence.
Your job is to ask why, figure out they always find water on the floor, and then look up and find there's a leaky pipe, then fix the leak.
In other words: do not really listen to the "implementation" or the "solution" customers propose. These only fix symptoms and are easily swayed by whatever piece with a clik-bait title prefixed by "This AI robot" someone with 2 minute attention span has written that the customer half read taking their morning coffee, and wanted to bring to the product not to be left behind by the competition.
What one really looks for is the problem. The problem almost never manifests itself, you have to dig to get it. It's muddy. People could be pissed at you because "What do you not get in an AI IoT robot that orders mops?". This is where having social skills and getting good at interviewing comes in handy.
People demands and their behaviors are the solutions they have come up with to a problem. The problem is that they almost never tell you about the problem, and you may have a better solution. Think of it like code review: code I push is my implementation or a solution to a problem. The implementation is dictated by my skill, experience, sophistication, sleep I had yesterday, etc. Code review helps find better ways.
Third: all developers do support. This focalizes and aligns everyone. You have a hundred issues in your issue tracker. You have thought of great features. A lot of the issues are about bugs.
We opened our internal ML platform to about 30 students of our colleague so they could get a one click notebook with all libraries installed, a lot of RAM, a sweet K80, and hundreds of gigabytes of data for their project. We added the students to a dedicated Slack workspace. The platform is not ready, but precisely. This is a jolt.
Users would complain about something. We would notice a pattern. We would investigate, then figure out what to do.
They're doing two things:
- Exposing things we wouldn't have found
- Putting the finger on what hurts the most amongst the issues we are aware of.
One person who complains about something is one thing. Ten people complaining about the same thing that prevents them from working, that's another thing.
We have worked differently in the past. There have been changes to the company and changes in how product development is done. The business side of our company used to talk to the executives of the client company. We have been paid for all our products, whe have shipped them to spec, none of them is used, none of them can be reused, all of them left us with scars, and that way of working almost destroyed the company.
Fourth: everyone should be clear on what the team is doing, and what the team is not doing. This issue is not a priority. We will handle this one, this one, and this other one by this date. This part is handled by this person. Avoid the "I thought Alice was working on it".
Fifth: -good engineering practices go here-. Good test coverage. Patches get their tests, good commit messages, root cause analyses, and eventually knowledge base. A test harness is not "directly" good for the customers, but it gives confidence that you won't break everything. Loosely coupled, modular code: it allows for people to develop with different speeds and reduces dependency on unrelated parts, which is really frustrating.
So let's assume you fall into the 10+ client category. The company should have a defined and published product roadmap that is being worked, new features should be vetted against the client demographic (e.g. it should benefit more then 50%, I usually set the bar higher early on like 80%) and if it passes that then it would be defined and put on the development schedule, but it should not disrupt the existing planned sprints on the roadmap. That means the client might have to wait to get this new feature, but the benefit is the product can be designed, kept reliable and stable and not get polluted with a bunch of make shift code and hacks. None of this has to be a crazy long process, it can be simple and quick and if sprints are 1-2 weeks, most likely many features can fit within the next 30-60-90 days at most (obviously assuming proper staffing etc).
The sales side of the business should never be in control of the development schedule, or product roadmap, it is a direct conflict of interest. Product management should be owned by an operations type person, CTO, COO but for sure a non-sales, and/or marketing focused person. This is what will make the company successful faster and help keep the product stable and on schedule. Founders when small have to wear many hats so they will be violating this all the time, but by the time they have hired a product manager, sales teams etc, the hacky crap has to stop if they want to succeed.
None of this means a client (or business) can't get a new feature turned around pretty quick, it just means that there is alignment of features to more than one client and that product stability, reliability and schedule are managed as first class problems. Startups struggle with this thinking it will slow things down, and they will lose deals, when in fact it speeds things up and makes everything more predictable. The key is requests can be done faster when the development teams can keep tech debt low and design things into the product properly. It also prevents the scrap it and rewrite it that happens when you don't plan well enough. To be fair, there is almost always 1-2 scrap code repositories early in the life of a startup, but it doesn't have to be that way, just usually works out that way because of people repeating preventable mistakes they haven't yet learned.
I do think it is important to recognize when you are first starting the company it is more free for all, scrappy and hacky, but even in those circumstances you should not be implementing features just because one client made a request.
The right way is to collaboratively change your roadmap over time. The wrong way is to restrictively stick to spec from the start.
Roadmaps are not things like Jira tasks, and vice versa.
I would recommend...
— keeping a list of feature requests sorted by popularity, number of client requests, and impact to your KPI / north star metric
— prioritize each milestone / sprint based on this list, this can be for the next week, month, quarter, depending on the complexity of the project, then measure
— agree with the management team to not change the priority midway unless there is a very good reason to do so
You can use a variety of tools to do this, from the traditional Google Suite of tools to more specialized task management tools like Asana, Trello. We mainly use a combination of GitHub issues and Taskade (our own tool) to do this.
I believe a big problem for getting a good product roadmap is very fundamental... we don't truly believe on the products we are working on or in the company we are working for. Is just a bunch of people with no real vision trying to influence one another over ego.
And then you have Sales of course who can actually talk smooth and influence better those who aren't sure about why they do what they do...
fraserharris (1) is about bigger vision. That's what I think makes a good product road map. A vision, extreme focus and caring about it.
In consumer, where the customer may not really know what they want, and can be convinced, it's more about vision and how that aligns with smart marketing.
With B2B the sales teams are it. Customers may also not know exactly what they want, but some discussion there will suss it out.
Note Apple was always pretty terrible in B2B, you wonder why?
I think sales is super important yes but it sort of works after having a product.
It is just as important for a company since no sales == no money coming in.
I guess in the context of this topic I believe that to manage a product roadmap effectively having a strong vision for the product is fundamental.
I always thought that was a strength, they focussed on areas that companies like Microsoft were completely oblivious to.
I don't really think salesforce's early 'no software' bit counts as vision either. Maybe.
There are huge swaths of mundane companies that make up most of the econony, wherein I would say there's a lack of vision in the way we understand it. What they have is operational tenacity, rigor, professionalism, and a near term vision to 'make money'. For better or worse, that's what we have.
And this is exactly what the agile/sprint process is extremely helpful for.
Every two weeks, check in with the business team to bring them up to date with development and get them to prioritize/rank the features they want.
Then hold a big meeting with your team and use planning poker to estimate how long the top-ranked items will take. Inevitably it'll add up to 2 or 3 months of work.
Then go back to the business team with the realistic estimates for each task, and get them to pick what is actually most important to deliver or make progress on in the next 2 weeks.
Then work on those for the following two weeks. Rinse and repeat.
The key thing here is that there is an objective process. Nobody can blame you or any single developer -- there is a process. And after several of these iterations, the process will build trust among everyone, instead of blame or suspicion.
Also, you might think this leaves you with no room for input of your own. And in a way this is true -- welcome to being a PM. Your job is to manage and balance other people's priorities, not your own wishlist of features. But it is crucially your job to advise well and point out inconsistencies/dependencies -- e.g. sales wants feature A but the CEO wants feature B... but if we deliver B before A then together they'll take half the time, or will enable feature C earlier, or whatever.
And it's also your job to keep your eye on the long-term goals, which will generally be set by the CEO or management team -- sometimes you have to deliver feature X that management requires by the end of the quarter, over anything the sales team wants -- which you just gently explain to sales.
Most business stakeholders will never be able to describe what they want in a way such that you can implement it. You will just have to live with the fact that you will often rework things you implemented because what you think you heard is not what they said.
2 weeks is an eternity is a fast moving business. That's more than enough time for stakeholders to change their priorities and to forget why they prioritized something in the first place. This will lead them to be angry that their current priority is still at least 2 weeks from being done.
Depending on if the team has done something like what they are being asked to estimate before or not, estimates will be low by either a factor of 2 or 3. This is true even when you take this fact into account.
No matter how many times you say that an estimate is a best guess, everyone else will take it as a promise. There is no way around this. Never use the word 'commit' because it will be used against you.
No one cares that there is an objective process once something had gone wrong, and they don't blame the process. They blame each other for either strictly following the process, following the wrong interpretation of the process, or not following the process. They will also argue incessantly over what the process actually is.
I don't want to come off as incessantly negative here, but you shouldn't pretend that there exists some method that will change the basic fact that your job is chaos management.
When a company works you don't hear about it. You just see their success, or maybe you don't since there's more to success than sound process. You always hear the bad and the ugly.
The software industry is plagued by managers without domain knowledge, people faking it till they make it and immature processes. I think this is probably the main reason you have had such a tough time all these years.
I think process definitely helps mitigate these things but you also need reasonable human beings at the helm. If a 2 week development cycle is not fast enough for you, then you have some serious problems.
> Most business stakeholders will never be able to describe
That's what planning poker helps with. The engineers envision what they think business wants. Then you go back with the estimate and a description of what will be built, and they either sign off or say "that's not it at all!" The latter happens frequently. You may have to do a couple rounds of planning poker, especially in early days.
> 2 weeks is an eternity is a fast moving business.
I've never experienced that. What industry are you in? Obviously there are urgent exceptions, but when you take into account design, engineering, testing, and deployment, it's hard for me to imagine things taking less.
> estimates will be low by either a factor of 2 or 3
That's what the points estimation and sprint burndowns are for. After a few iterations, estimates become surprisingly accurate. (They never are at the start.)
> everyone else will take it as a promise
You need management's support for the process. And it takes a lot of communicating. 10x more communicating than you think it will.
The rest of it sounds like you work somewhere that's pretty toxic. And of course no process can fix that. But if you call your job chaos management, I highly recommend looking for a new job. ;) That happened to me as well at one unfortunate job...
They get very rough estimates from engineers, then sit down with the other PMs and business leaders and fight it out for engineering weeks. If the PRD is funded, they'll sit in sprint planning and demos, etc. to oversee the fulfillment of their vision. (The product's tech lead is responsible for architecture and implementation, the PM for its observable behavior and fielding). They'll participate in the design of test cases, rollout plans, experimentation, marketing materials, press demos, etc. They'll be on video calls at all hours of the night working with regional stakeholders around the world to clear the way to rollout in those markets.
Then at the next six-month planning cycle, rinse and repeat.
It is very much their own wishlist of features, although to get engineering weeks they theoretically need an evidence-based argument for why those features are the best use of time.
Maybe we're talking about the difference between PM at a product company and PM in internal IT?
Now draw lines between all the circles. Those are your lines of communication without a PM. This is a sad diagram, no one knows the whole story.
Now repeat the exercise but draw an additional circle in the middle of the page.
This time, the lines on the left and right connect to the middle circle. This is a happy diagram, the developers aren’t pulled in a dozen different directions and one person has the whole picture.
That is the role of a PM.
There’s a lot of assumption built into the framing of your question. Why do you think a PM is a middleman and only creating meetings? Is this based on some experience? Why is your premise that the business team owns the roadmap? Bad PMs do exist, just like bad managers, and just like bad engineers. If that’s where your question is coming from, I’m sorry, but please don’t assume that a bad experience is universal; it’s not.
In a business, there usually needs to be a healthy tension between what sales and marketing ask for, what the executive leadership see in the future, what customers need (which is not always what sales and marketing are asking for), what is on the engineering backlog, how difficult features are to implement (both how long, and also how disruptive they are), and anything the product needs that is not on one of those previous lists. When one team or one point of view dominates, bad things tend to happen. If sales and marketing gets to dictate what happens and engineering is relegated to implementing whatever they say, the roadmap can be too short-term and full of churn, it will lack focus and forget about existing customers. If engineering has complete control over the roadmap, it sometimes drifts away from what customers need and toward what engineers like to do, with solutions that are neat but overly complicated or using new technology for the sake of learning. You need a little of each, as well as some pushback from every direction to keep everyone happy. A PM has their work cut out for them.
I don't agree with the "no room part". It seems you don't work as PM but more like a mayordomo like job.
Just be very good at measuring and presenting data from all the channels in your company. Your customers, your prospective customers, your customer engineers, your sales people, your support team, your engineering managers, directly from developers too.
Understand the real cost of each feature. That's not easy. Try to predict the real value of each feature. That can be even harder. How many customers are asking for that feature? What's the avg LTV of that cohort? Will the feature reduce churn? By what percentage? Own those metrics and tell the whole company that's why you're prioritizing those specific features.
Be prepared to go back and check your assumptions and see if your predictions were correct...If you were wrong, then your next job is figuring out why and then working towards improving your own models to predict the value/cost of each feature. The fact is once you start intensely measuring that type of data, you'll find lots of gaps in your own process and fixing it as you go.
On my end, I’ve recently started working on documenting (still very, very early) on the “measuring” part at https://datadriventeam.org. It is backed by an open source GitHub repo and I hope people would contribute once I’ve gotten the initial version out.
Unless you're actually billing hours to customers for features, the features you add are yours. Sell what you have now, do not sell based on a future promise.
You need to balance the value of a single customer against the opportunity cost of not building a feature that all customers want.
The way I've found to do this: Qualify every feature request. Get in touch with 10 customers and have a list of the outstanding feature requests, and give them a virtual $100 and say, if you can spend this $100 on these n features and you only have $100, how would you spend it? Then take the answers from the 10 customers and see which added to the highest $$$ income. If a single customer is an outlier with all $100 on one feature, establish with their account manager the state of the account, are they happy? At risk? and prioritise accordingly.
Throughout this process, always have your vision hat on. Is the ask for "add this toggle" or is there an underlying common theme that a different approach could satisfy. This is the "most people wouldn't ask for a car, they'd ask for a faster horse" (not said by Ford but always mis-attributed) symptom... you need to see how features align to your vision, and bear in mind that the customers today may not be the ones you need in the future, startups go through wave of customers and you need to be working up that food chain, so what are the right features to satisfy needs, but put you on a path to the customer you want in the future.
Oh, and I'm an engineering manager not PM but had my own startup and had to do this stuff.
* Follow your vision for the product - i.e. form a feature-set that combines the greatest compatible combination of requested features and your understanding of what the future of the product post those features will look like
* Solve the immediate next problem that will bring you most money fastest. Apply debouncing. i.e. the next blocker to money is feature A in the shape of a customer saying "we're ready to sign if you have A". Rank all amount of money, likelihood of customer actually executing (if you aren't able to sign on to a pilot w/ "we'll have it next week"), and divide by time. Do that. Do not re-evaluate for some duration of time.
* Find what you're selling. Sometimes this can be very different from what you're making. And the customer may be asking for a feature because they think that feature in the thing they're being sold will solve the problem they're having.
Honestly, no one here can help you with this. I suspect not even a course could help you with this. This you're going to learn by attempting to constraint solve here. Just learn from the pain fast and do what's necessary to keep the trust of your team (primary!) and your customer (secondary because there's more of them than the team).
* Developer context switches are expensive (both in terms of developer happiness and productivity)
* Forks staying off main branch are expensive.
* Components/Modules being half-polished due to changing priorities are expensive (both in terms of customer satisfaction and introducing technical debt)
So for me, who is in a similar position, it's always a dance between what clients want, what management wants and what would keep my developers productive and happy and my product technical-debt-free.
If there's something that my clients ask for and it's really easy to implement, I would often ask my developers to drop other tasks and implement/hotfix it. But I'll try to redirect some good feedback from the customer side to the developer because I know they feel exhausted by changing direction.
Sales leadership should know that they need to build a sales team capable of selling what you have now while providing a vision of the future. Just guessing, but it appears they are caught up in trying to sell using features rather than selling your product as a solution to the problems your potential clients have.
If they can not sell the solution and keep getting caught up in a feature to feature competition, your company is in significant trouble.
That said... the feedback from potential customers, new customers, current customers, what you see competitors doing, your support organization, and the engineering team plus your vision of what the product needs to become are all critical for you making decisions on what to build.
As many here have said, there is much more to your question than can be answered here. I'd be happy to talk if you'd like to.
By the way, I have a single KeyNote slide for our roadmap. Not fancy, but it is simple, cheap, and gets the job done so we can focus on the product.
Like the difference between Test and QA. Complimentary, but still distinct.
Marketing's job is to divine the business case. Size of market opportunity, price points, window of opportunity, initial MVP thru mature feature set, projected P&L, and so forth. While collaborating with devs, for sanity checks and buy-in, ideally.
Real marketing is a real job with real skills. Once you've seen a pro in action, it kind of ruins you for all the pretenders.
In my 30 year career, I've worked with precisely 2 marketing pros.
(Sales pros are pure gold too.)
PS- Lisa Horwich is one such marketing pro. If your product has a business case, she'll find the critical path. Watching her in action still seems like magic to me. https://www.linkedin.com/in/lisahorwich/
1 Clean up shop. Set expectations & bounds. Throw out your backlog. Tell everyone you will release one BIG THING and X minor bug-fixes every month. Your job is to give the engineering team enough space to do their job well (including refactoring, compliance, security etc). And its their job to make sure that one, well specced, well sized BIG THING releases on time.
2 Business team, with your help, has 12 attempts a year to try to release features that will significantly up the growth/revenue of your company. Make yourself available to them to learn more about the customer and business needs and spec out your BIG THING each month. This has to involve a huge amount of actually talking to customers. If not, its pretty much guaranteed to fail.
Seems basic but theres a lot packed into the rational, like:
- Non-tech folk don't know what a big thing is, so you have room to play and overdeliver (important for your engineering team moreso than you).
- Reduced feature throughput generally means you only focus on those features that tilt the needle. Cant underestimate how important this is! Esp if your a fintech startup. Our products are notorious - 5% of features account for 99% of usage.
- Reduced feature throughput also allows you to spend longer speccing / talking to customers & business teams reducing the risk of mid-development scope creep or problems on release.
You said:
> This has to involve a huge amount of actually talking to customers. If not, its pretty much guaranteed to fail.
Do you have any advice for doing that well?
There are endless frameworks for balancing these choices. For me, they all come down to this:
Value
1. Dollar value; in either revenue unlocked or money saved (and money can be customer support time)
2. Strategic alignment; how is the item aligned with overall vision & goals? If this item is completed, does it make us stronger or dilute our value / competitiveness? This is really where stage of company comes into play.
...vs...
Cost:
1. Time; Estimated time to build/support. This can be a wag from the engineering team.
2. Risk; what is the uncertainty around the time and maintenance estimates?
Using a framework like this allows you to include architecture, technical debt maintenance, etc into your overall planning and decision process. This will help make visible to business stakeholders the true complexity of operating the product and hopefully lead to better PM decisions. Everything is a trade-off.
Remember: one of the most important jobs of a PM is to say NO. You are the process gatekeeper to how the company spends a ton of resources.
Happy to discuss further.
If you are building enterprise software, vs hardware, vs consumer products...the process can be very different, with different balances on risk and very different timelines
Reprioritization is good and normal, but decision makers need to understand the costs and a good roadmap allows you to communicate that better.
> business team is constantly changing priorities based on new client requests
If you have a separate "business team" that changes the priorities, they are managing the roadmap, not you. If you have a situation where you are accountable for the roadmap but other people get to make all of the roadmap decisions, you are in a very difficult position. The most important thing for you to do is focus on communication and clarity.
If you aren't already, you need to be tracking everything from week to week. Record a snapshot of the priorities on a given week, along with any "business team" inputs that change the priorities. You need to be able to show in detail where each priority started, stopped, paused, or was re-ordered. You also need to be able to show who directed the priority change. Work on a report or slide format that can clearly show how the priority list has evolved over the course of the year, and don't be afraid to put names next to each priority change ("Moved to #3 priority on Mar. 3 after request from Bob").
If the priorities are constantly churning to chase whatever client requests are coming in, the sales team has hijacked the PM process for their own personal gain. The best way to push back against that is to shine some light on it by tracking it, visualizing it, and communicating it with leadership. Once you make it clear and obvious, it's much easier to get leadership to clamp down on priority changes and drive toward some commitment.
But as long as the business team can quietly reshuffle the priority list each week and let other people suffer the consequences, nothing will change.
While this may sound like it's easier to manage it usually ends up with a product that does not solve the problem of the customer.
As a product manager solving problems of your user or customer must be the first priority. The only way to do this is getting closer to the customer.
I find teams shielded from customers via business teams use the best part of their product management and engineering skills (microservices included) to manage their business team and not the customers.
There is a constant grooming of the backlog with features and pressure to keep the engineers managed and busy.
Start measurning the value of each feature to your customers. Have short customer feedback cycles for planned features. Your backlog should reflect solutions that make sense to the customer.
The book "Escaping the build trap" talks about this. I highly recommend the book.
Good books on the subject talks against roadmaps and shifting to a value and goal based approach.
1) Teach your sales team how to pitch your product roadmap, so that customers are buying into the bigger vision. When customers are bought in, they will accept that they don't get their small feature because they will gain something larger faster. Sales LOVES when this is successful because then their deal can close faster.
2) Challenge the sales team to find at least 2 other customers that need the same feature before you agree to re-prioritize your product roadmap. This creates alignment between them & your need to prioritize the most impactful features.
There are multiple reasons for changing priorities.
Are there multiple business folks all generating requirements independently, insisting that their client is the most important? Get them all in a room to hash it out. Either they all agree on a ranking of the clients, or they each have to prioritize their own requests and choose a small number (say, 1-3) of truly critical requests to put into the engineering queue. If they can't agree on this, escalate to the CEO. If the CEO can't/won't prioritize, you're in bad shape. Your best bet is to make a judgment call as to which clients/features are truly critical and drop the rest on the floor. Be prepared to send out your resume if you make the wrong call.
If the clients themselves can't decide what they want, or can't communicate it effectively through the business team, you need face time with customers. If you have a product-minded engineer who is good at speaking the customer's language, include them too. The more direct exposure and intuition the engineering team has about what's really important, the more support you'll have in making those calls.
* Focus on outcomes over outputs. Your job is not to build a spreadsheet or JIRA backlog of features and then hand them to engineers to build like a coding factory. You do not have a crystal ball. You are not Steve Jobs.
* Involve the Business, Support and Eng parts of the org when defining _what_ to build. They all bring fantastic perspectives and really helps focus on the MVP and creates shared buy-in. Remember you are trying to solve a business problem not just crank out features aimlessly as a team.
* When mapping out _what_ to build, it always helps to use the collective team (in previous bullet) to outline Effort vs Impact. Forces really good discussion to keep things hyper focused and efficient.
* Instead of focusing on features focus on the strategy and the vision, let the team figure out how to get it there. As a PM you need to understand the market, the competitive landscape, how people are pricing their products, what customers are saying, industry trends, etc.
* Roadmaps in general are somewhat useless bc you don't have enough information and they create a lot of emotional commitments. Things change (hello Covid-19) and you don't know what you don't know. Instead outline your vision and strategy at a high level and make sure they are aligned to your overall business outcomes. This prevents people from saying "You said we would get feature X in Q2!!!". Instead you focus on metrics (Decreased Churn, Increase engagement by 3x, returning users more than X times in Y days, Revenue, etc).
* Be religious about data. Define your business outcomes, have good tools to track the progress of those outcomes, have a way to test/validate quickly and pivot as soon as it doesn't work. Keep fine tuning the machine
Long story short: we NEED user feedback but it cannot dictate the roadmap (and therefore the mission). If you find yourself repeatedly needing to change your roadmap it might mean you're too quick/loose adding elements to it.
Hope this helps!
Listen to your users but don't trust them.
In general, you should have an idea of the next projects you are going to work on. When customers give feedback, that can help to reorder the projects. If you are doing your job correctly, there won't be any huge surprises.
There will be occasional one-off customer requests. We call these "customer love" at my company. We reserve some percentage of our development time (maybe 10-20%) for doing these, because they do create a lot of goodwill with customers. But you have to be pretty disciplined about making sure that they are 1-2 days or less of work and not 1 or to months of work.
There will occasionally be things that customers demand as part of a deal cycle. In some cases you have to build these, but it is important to explicitly highlight what you are foregoing and to be conscious of this tradeoff. Note: hiring contractors doesn't really work well, because someone will have to support it (just went through this).
The first thing you should do is create stability within an ever changing business environment and also capture the cost of the priority churn. So create a roadmap, and have a process to capture priority changes, and how much WIP work is wasted (=not shipped, as it’s deprioritized) as a result.
There’s a bunch of tools and methodologies you can use for this. Sprints, scrum, OKRs etc.
As an engineering manager in a similarly fast-moving environment, the two main rules I follow are: 1. We don’t do any work that does not have impact defined: what happens or what we expect to happen when this project is shipped. This is usually in some numeric value. And we always work on the best impact/effort project next. 2. The team _always_ finishes what we start and we do small enough work items/milestones that enable us to iterate quickly.
Good luck!
What I am suggesting is, you take a bunch of requests, but manage two roadmaps. One is the feature roadmap with reasonable dates, the other one is the release roadmap which lags one week for each feature. So once you release that awesome backtesting feature, you've been testing it internally since a week and finding bugs as you go. Do not release when done with a feature.
This runs really counter to my instincts. The first thing I wanted to do at my current job was move from weekly deployments that were lagged by a week of QA to nightly deployments behind feature flags, so product managers could launch quicker, allowing faster feedback loops.
This being said, if the roadmap changes mostly based on new customer asks.. then you're not building a product, but doing custom development / professional services work.
This interference-from-above characteristic can work if a PM is new to the job, but ultimately results in a PM having all the exposure (ie, organizational risk) and zero influence. That's a hopeless scenario & all too common because the vast majority of orgs have no idea what a PM truly is.
So I want to know if the OP has the freedom to defend his convictions. It's not about tools. It's about responsibility.
You should most certainly listen to your customers, after all, if you're not serving them, what's the point in the product? However, you shouldn't be reacting to their requests to the detriment of the product either.
Do you AB test new feature ideas? Do you gather data to suggest that the requested feature is actually going to make a positive impact? Do you measure impact after releasing a feature to see if it was the right call? If not, how the heck can you ever actually know if you're building something better?
You don't need to ignore your customers, but you also don't need to change priorities so often. Make a roadmap for X months and stick to it (we use 3 months, but something else might work better for you). Use the time that the roadmap is being worked on by the tech team to do discovery and research so that you know what the most valuable requests from your customers are. Collect metrics, create prototypes (design/ux prototypes, not technical prototypes) and test them with your customers, do customer interviews. Then when you're ready to, you'll have better prioritisation, and your teams will have had the space and stability to release the previous features (and hopefully had tech investment time as well to keep your systems maintainable).
Customers' needs should always drive the product roadmap. That said, it's not uncommon for customers to not know what they really need until it's already been built. This is where the Product Manager comes in to the picture. The PM needs to ensure everything added to the roadmap is of the highest priority and will solve real customer problems or have a positive impact towards the org's key objectives.
A couple tips that may be helpful for you as you navigate this situation:
1. Before any feature-specific debate, you need to be closely aligned on the overall vision and objectives with your key stakeholders, including the "business team". What are your most important objectives to hit this quarter, this year? Growth in active users? Increased transactions? Improved bottom line profitability? etc. Once this is aligned on, it becomes much easier to have these prioritization/tradeoff discussions.
2. Many "business" teams and the leaders of those teams don't understand the basics of software development. Over time, it's beneficial for the PM to help educate key non-technical leaders about the costs of constantly changing direction. Help them understand how technical teams plan and execute, and show the impact to timeline and quality when reckless decision-making gets in the way of the engineers doing their jobs effectively. I like to this of this as a "help them help you" mindset.
A roadmap is a tool for communicating long-term direction and priorities. By making clear what the ultimate destination is, a roadmap helps you keep steady on the those priorities when doing your sprint planning. When sales says "we want this feature to close this deal," if it's something already on the roadmap, great. If it really doesn't fit with the long-term vision, you have a basis for saying no.
I wrote a book on this topic, Product Roadmaps Relaunched, Setting Direction While Embracing Uncertainty, for O'Reilly a couple of years back that goes into more detail: https://www.amazon.com/Product-Roadmaps-Relaunched-Direction...
> Good PMs know the importance of talking to customers frequently. Good PMs listen intently to customers to develop their product hypothesis. Great PMs also listen to what isn’t said and anticipate where the industry overall is headed when developing their product hypothesis.
How do you think about balancing data (customer) driven approach and product vision? This is an age-old question. I sided with the former and am learning that there's also wisdom in the latter. This might be a better way to put it: there's time and place for each approach, in a product's life cycle.
https://firstround.com/review/This-Product-Prioritization-Sy...
You've never met a salesperson, have you?
In my experience, feature requests are someone's best guess as to the solution to a problem, but often without the problem statement. When you ask about what problem the request is meant to solve, you come to understand your customers -- even better, you realize there is a much shorter list of important problems than of feature requests.
Focus on solving those core problems and most of the feature requests will melt away.
Another good place to start is the Ultimate guide to OKR: https://www.perdoo.com/the-ultimate-okr-guide/.
Hope that helps!
I've been looking into ideas like No Estimates and delivery forecasting as a replacement for 'traditional' Scrum-flavored agile, but AFAIK these newer approaches aren't very battle tested.
This is called a "thematic" roadmap or an "outcomes" roadmap. It is well described in this article: https://www.prodpad.com/blog/the-birth-of-the-modern-roadmap...
The PM is the hub of communication between all 4.
Although on a day-to-day basis, it's the dev team and business/sales that make up the large majority of interaction.
Check-ins with management are occasional, and conversations with customers are just kind of an ongoing informative thing.
In the example, every one of those lines consumes resources: time, context switching, misunderstanding, synchronization with the rest of the team.
A quality PM funnels all those lines through themselves. Their value is proportional to their ability to (a) bidirectionally extract, transform, and deliver useful information to both sides (developers and end users), (b) offload processing tasks that neither side is good at (merging similar requests, clarifying ambiguous requests, tracking down answers / requests for external teams), & (c) keeping a 10,000 view and coordinating tactical requests to align with strategic vision.
I like the CDC 6600's peripheral processors ( https://en.wikipedia.org/wiki/CDC_6600#Peripheral_Processors... ) as a computer hardware metaphor.