Developers is still too broad, that's for sure. I would have started by spliting it into problem domains: enterprise apps, enterprise middleware, enterprise foundations, consumer apps, etc. For each of these, I'd identify salient requirements: enterprise apps need to be easy to build, handle lots of form-ish data, connect with disparate systems; consumer apps needs strong branding capability, etc. As with any market analysis, this would include information about size of market, number of dollars, how the customers behave, etc.

I would then have identified our core competencies: amazing browser interaction, strong form builder, strong component re-use architecture, automated version control and deployment to the cloud, etc.

Take the first, overlay it with the second, and start sorting by "closest" and "number of dollars."

The closest we were to identifying a market was (more by default than choice) "consumer apps." Unfortunately, that's a really bad market for development tools because there are so many good, free ones available.

We later tried switching to enterprise apps, but we had significant deficiencies there (poor integration support [great web services support, good RDB support, but no other integration options], no on-premise deployment (a real problem for most enterprises, especially two years ago), among others.

Since we weren't willing to commit to that market segment to fill the holes (instead, focusing on developing a little of everything), we couldn't build a compelling sales story.

Ultimately, the problem was they put their headphones on, started coding, looked up three years later, then tried to scramble to figure out how to take everything they'd built and get people to use it. They should have started from day one looking for customers to work with, started telling their story to see what resonated, and adjusted their roadmap to match.