How do you balance building features customers are asking for vs. bugfixing vs. features that will move the needle in your opinion vs. not coding at all and just focusing on marketing?
One approach to prioritizing building features customers want is to count how many times the feature has been requested. Let's say 10 customers requested X feature. Reach out to them and ask if they'd be willing to pay more for the feature and if they would, you'll prioritize the feature in your next release. The value/price decision helps customers determine how bad they want X feature, and it also allows you to prioritize purely on ROI.
As far as bugs, I'd say you organize by most reported and knock out the top 3 (or whatever you have time to work on). Obviously if the bug impacts user happiness then you should fix it ASAP.
Focus half your time on coding, the other half on marketing. I think this approach will keep the ball evenly moving forward.
Hey @royceh, what tools are you using to manage your roadmap + customer contacts?
@wasabigeek I don't create a roadmap. Instead, I typically write out 1 to 3 goals I'm trying to reach in OKR format then keep a running list of ideas that move the need on one or more of the goals. I like this approach because a roadmap feels more like a waterfall approach versus start with a goal(s) and brainstorm ideas to achieve those goals. However, you do want to prioritize ideas based on highest impact, reach, and minimum effort. I typically try to prioritize ideas at the beginning of the month.
For customer contact, I send an email out to users (via mixpanel) that are "activated" on my side project asking how they would improve the experience.
Check out Canny.io
Create a long term road map and align each activity/task with road map. create sort term goals from the high level goals and try to assign items to short term goal ( if item cannot be aligned then that is not a priority) . try to win one battle at a time and you will win the war. always keep focus on one short term goal at a time. focus on each of the category bugs/feature/business buy either dividing days of week for for categories or time of the day. I personally divide my day in two part 10.30 to 2.30 is time fixed primary goal and post 2.30 is all about external meeting/phone calls/sales/business/book keeping etc.
This is really great actually. Tougher for me because I only have a few hours a day so I have to balance product development with sales and support.
Currently at my company we do this based on votes per feature. The more companies that request a feature, the more attention it gets. Bugfixing takes time and squashing. But building out the platform is also vital. If the customer is asking, paying and it affects more than 50% of our users. That's the one.
I can tell you what we do, but every company is different. For us, we ship 1 big feature at a time, followed by a week (or so) of bug fixing and small features. This works for us because we're shipping constantly and after a week we've got some data on usage and user feedback for the next round.
The other benefit, we've found, is that we have more time to think about the bugs before immediately solving them. Numerous times we've thought of new features or much simpler approaches just by letting it sit for a bit.
As for coding vs marketing, I think that's just how you prefer to work. I like to take entire days as "code" days when I'm committing or "non-code" days when I'm opening issues, doing customer meetings, etc.
I have found this to be surprisingly overwhelming. There are so many tasks, each one with varying levels of risk and reward. You can make lists, but so much of it comes down to gut and intuition.
Sometimes we think having a successful business is about coming up with a good idea, like it's one big decision we need to make.
In reality, it's like there are 10,000 little decisions. I think success comes to the person who can best make those 10,000 little decisions.
Man this feels so true.
I've got 1-2 hrs a day, but I end up spending all my time at my day job thinking about all the other little things I should do, each of which takes 1/2hr or 45min. So I'll hit a coder's block just devising what to do next.
I hear you! I have a couple hours each morning before the kids get up. So little time to get in the groove!
For cronhub.io it's a combination of user feedback and my own intuition. I think until I have enough customers using Cronhub I'll be sticking with this path. When I have enough customers I'd probably start making decisions based on the data making the product more data-driven.