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.
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.