For us, it was always about building a product our customers love. Part of our motivation came from the frustration we had with other tools, but we never intended to build Codeship only for us. That mentality influences how we think about getting feedback. We always want to understand what problems our users are facing and how we can help them best. It's often tricky because, on the one hand, we want to help them and understand their use cases, but on the other hand, we also are opinionated on how you should do things.
Happy to share more of our processes of how we handle the feedback, who looks at it, how it flows into our product roadmap and so on if you are interested in that.
For us, it was a mix. We had some ideas, build an initial prototype and then iterated over it based on customer feedback. It wasn't well thought out, we just tried to balance our ideas as best as we can with what customers wanted.
Now, we try to do it a bit more formalized. We spent quite some time fine-tuning our product strategy and derive our product roadmap from there. E.g. we're heavily focused on Continuous Delivery, not just Continuous Integration. That means that we tend to prioritize CD features higher than new CI features.
What we think we should do is captured in our product strategy. How it should look like in reality is defined by the customer feedback. That's probably the best way of putting it.
Something that helped us a lot as well is clearly articulating what we won't do. E.g. Codeship currently doesn't do CI for iOS apps and clearly spelling that out and referring potential customers to other great solutions out there (e.g. Buddybuild, Bitrise, Nevercode, etc.) saved us a lot of time.
I think it's equally important to know what you don't want to do.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Since I'm also in the business of developing for developers, it'd be great if you could share how you handle user feedback.
For us, it was always about building a product our customers love. Part of our motivation came from the frustration we had with other tools, but we never intended to build Codeship only for us. That mentality influences how we think about getting feedback. We always want to understand what problems our users are facing and how we can help them best. It's often tricky because, on the one hand, we want to help them and understand their use cases, but on the other hand, we also are opinionated on how you should do things.
Happy to share more of our processes of how we handle the feedback, who looks at it, how it flows into our product roadmap and so on if you are interested in that.
For sure! Would love to hear how that all works.
For handling feedback, I always welcome requests but I wonder how to draw the line between listening to users and building what you think is best.
For us, it was a mix. We had some ideas, build an initial prototype and then iterated over it based on customer feedback. It wasn't well thought out, we just tried to balance our ideas as best as we can with what customers wanted.
Now, we try to do it a bit more formalized. We spent quite some time fine-tuning our product strategy and derive our product roadmap from there. E.g. we're heavily focused on Continuous Delivery, not just Continuous Integration. That means that we tend to prioritize CD features higher than new CI features.
What we think we should do is captured in our product strategy. How it should look like in reality is defined by the customer feedback. That's probably the best way of putting it.
Something that helped us a lot as well is clearly articulating what we won't do. E.g. Codeship currently doesn't do CI for iOS apps and clearly spelling that out and referring potential customers to other great solutions out there (e.g. Buddybuild, Bitrise, Nevercode, etc.) saved us a lot of time.
I think it's equally important to know what you don't want to do.