Help! How to REALLY prioritise when you have some traction and conflicting requests?
As startups go through their runway, resources thin... dev teams may get smaller (or not) and traction is going up, as traction goes up and time passes - sometimes we have conflicting priorities; web app, desktop app, android app and improving the iOS App.. Fellow startup founders, how did you decide what to do next? (aside from using the usual RACI/product prioritisation methods)
Have your company and coworkers have a vote and argue the best point as to what needs to be prioritized. I always have standup meetings with every member (even if its 5 mins a day) to set expectations and to keep everyone aligned. I would also make a list and rank from from highest to lowest priority and share that with the team each day to keep them and yourself in check! :D
That’s a constant question for us, especially if it’s between features we think the existing community will love vs. ones that will expand that community. Often we just deliberate until we find a path that hits a lot of different notes at the same time. We’ve delayed launching our android app for months now (released iOS in January). 90% of mobile hits on our website are from iOS, and we want to build one product really well. Launching across platforms slows down each future release cycle too. Depends on your audience, but we don’t regret the decision :)
Check the impact of the task 1) Production P1 super high priority since it will lead to disruption of the business 2) P2/P3 can be taken as per the gaps If it is development tasks 1) Look for its potential impact in terms of operational hours saved or increase in sales 2) Prioritize on basis of that There are other considerations also, suppose impact is high and it has large ETA then break the tasks into smaller deliverables (if possible) If not possible start 2 tracks 1) Impactful and longer 2) Impactful and shorter start both the tracks since but are important, do not ignore the impactful and longer track since it will help in visibility of the work Impactful and smaller gives quick wins and keeps the morale going. Hope this helps
This is a great question and something I think we all struggle with. You've probably heard this before, but internal priorities should usually be validated by external priorities. This means that what gets built/created should be things people are asking for. When people ask for everything, you need to decide what will bring the most upside the quickest. Everything needs to get done, so I try to prioritize the easier, more immediate things first and work on the longer and more impactful items later when we don't have so much on our plate. I hope this helps!
@paul_vanzandt Indeed it does, we've been adopting that approach but sometimes we end up building some technical/UX debt because they aren't full flows that are developers but more parts of features that users want vs. what we had intended/planned for. But definitely, your comment brings me peace that we are doing things similarly!
We use this system in our team: First, we decide on important attributes (as a structure of our decision making) and score each from 1 to 5 for each feature: Benefits: - Revenue increase - Valuable to customer - Strategy-wise importance Costs: - Implementation Costs - Operational Costs - Risks When we want to plan for our next product sprint, we score all these metrics for each feature. And calculate any feature's rank based on this formula: Total score= Sum benefits score - sum costs score Then you can see a list of features, each with a single score. Sort them from largest to smallest and you'll have a prioritized list of features :)
RACI and bringing things to a consensus vote within your team if you have the time, but if you dont have the time, I would think you have to trust your gut. I do think that Customer service, Product uptime, the marketing go in that order though. With respect to the different implementations (mobile vs desktop) thats business specific, in that case I would weigh where paying customers are most likely to come from and go from there. If triaging, do what you must to keep the doors open and cash flowing
We ran into this issue alot last year. If you just create a list of To-do's, you'll end up with a list of 1000 things to do, and 95% of them won't get you closer to achieving your goals. From a planning perspective: We found that working in 6-8 week sprints, with very focused Goals and Strategies planned out in advance helps us ignore the 1000 other tasks and ideas that we think of. We start with a SWOT analysis to understand how the business is running, where the opportunities are, and what goals we need to accomplish in the next 8 weeks. Then we create a sprint map, and outline what we need to do to accomplish those goals and prioritize them. Anything that's not on the sprint map, we count as a distraction and ignore it (unless it's an emergency). Unfortunately, doing that means a lot of little things just won't get done, but your organization will move much faster because of it. From a leadership perspective: Having a standup meeting at the start of everyday helps you unblock internal efficiencies, get employees collaborating with each other, and priortizes what everyone needs to do that do in alignment with the sprint map.
@luke_mondora Thanks a lot for taking the time to respond! I appreciate a lot your answers! We worked with sprints and found them useful to keep us focused, haven't tried such long sprints but could be an interesting approach :) I like the SWOT input -> could be good for competitive mapping as well. Thank you!
@komalnarwani Thanks for the reply. 8 weeks is definitely a long sprint! But I guess it depends on what department or function it plays in the business. If it's building new features, then it may be too long. But if it's marketing, then a strategy might be Acquiring customers off Facebook, which may need a full 6-8 weeks to determine if there's a future there. If it's exploring new product ideas, then taking 6-8 weeks may give you enough time to research scope it out, and validate that your audience would buy it. We also do a significant amount of user testing and pre-testing before launching experiments, so that makes things a little slower to launch.