Today, we’d like to give you a brief look behind the scenes of how we plan our product features.

After many years in the digital product development business, we have come up with many workflows how to track feature requests and how to plan their development. However, we’re always open to challenging our workflow and tool stack to streamline our work.

In fact, one of our five company values is to: Work smarter, not harder. By that, we mean that:

  • we value results over working extra hours,
  • we focus on customer delight,
  • and we trust data over opinions.

Until recently, this is how our workflow looked like:

  1. Our community (users, leads, fans) were able to report bugs on GitHub or suggest and upvote feature requests on UserVoice. Also, we would get a ton of feedback from our customer support channels (Intercom, Twitter, Facebook, Slack Community…).
  2. Our product codebase is quite robust, so we have to plan before we edit its parts. Having built to solve hand-off for our team just as for the community, we have a pretty clear idea what Avocode should be able to do. We believe that focusing on technology first pays off in the long run. That’s why we have dedicated a reasonable amount of time to build a custom rendering engine. So whenever we receive a new ticket with a feature request we need to balance the importance of such feature against the performance of our underlying technology that needs to work seamlessly, otherwise, any other feature wouldn’t be relevant.
  3. When the market moves — for example when a company like Adobe offers us a partnership to integrate with Adobe XD — we need to be agile to make it happen. These things are hard to plan for, however, they need to be done, because their impact is significant.

As you can see, the feature roadmap is always a compromise between these three inputs: community, our product team, and the market shifts. And as you can imagine, managing so many inputs and deciding which goes first can get messy and demands a lot of time.

First, we needed to merge the place where we collect feature suggestions with the place where we prioritize our roadmap. Not having these two things together made it difficult to regularly check the input from our users.

After trying a few solutions we ended up with ProductBoard. It allows us to add context and customer qualitative feedback to particular features. This way every opinion is heard and considered and helps us define the development brief for our product team.

While we have multiple product oriented people in-house, to keep challenging the way our product works, we need to invite more people to the table. Therefore we have asked our customers, our Slack Community and also the whole team at Avocode about what could be done better in the product UX. For each issue, we have asked the respondent to evaluate how critical this issue is.

Then we poured all the inputs — both from our customers and our team to the ProductBoard (this was actually our way of testing it) and we came up with 10 most pressing areas of our product that need enhancements:

  1. Versioning
  2. Image export
  3. Previews on design tiles
  4. Tags, sorting, file management
  5. Variables
  6. export settings
  7. Style Guides
  8. Notifications
  9. Billing
  10. Comment mode

Eventually, we have decided to dedicate a full company sprint to come up with quick solutions. Then the entire team was divided into new teams based on who wanted to solve what and at the end of the week, there were 10 presentations, with solutions that were new and completely out-of-the-box — because not only product people were involved.

What did we come up with? Some great stuff like version commit messages, filters for comments, or simplified image export. You can look forward to most of these enhancements in our upcoming updates.

Last but not least, we have a pool of improvements and features in our pipelines, so how do we decide what to next?

Only because some features are on the top of the list, it doesn’t mean it’s possible to build them in chronological order. Most often they concern different parts of the Avocode codebase. So before we open our code to edit it we do one more round of evaluating the priority of the feature.

We also figured out a way to connect product development with team management. For example, our last major update — Avocode 3 — was planned for almost a year. The whole team knew what’s the goal we’re going towards and what features are key to build before we can ship it. For example, this update included features that were upvoted over 2000 times. However, we didn’t ship the whole thing at once. Instead of having our users wait for a major update, we roll our smaller updates, around two times a month. This way it’s easier to test the app regularly and collect and implement feedback continuously.

To wrap up, again we invite you to submit and rate new Avocode features (for the time being still on UserVoice) as well as test Beta pre-release versions of the Avocode app in our Slack Community. FYI, there are some perks (discount, stickers,…) for those who give us more in-depth feedback at least once a month.

And how do you plan future releases and optimize your product roadmap? Let us know in the comments.



Source link https://blog.avocode.com/how-we-come-up-with-what-to-build-next-for-avocode-4c25452752e2?source=rss—-3d381deaf83—4

LEAVE A REPLY

Please enter your comment!
Please enter your name here