Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Wholehearted agreement with Owen's post.

On point #2: describe your product in clear, what-it-does language.

Mistakes I see are emphasizing: how it does it (C, Java, OO, Rails, REST, ...), where it does it (PC, mobile, Mac, Cloud, ...), "ecosystems" it integrates with (Social, FB, Oracle, ...), who your investors or team are (VC, founders, investors...) etc. All of which may or may not be particularly relevant, but ... they're not key to me understanding what you do. Tell me these things, but focus on the what first.

Use direct, actionable language, not vague or nebulous terms. It's a "NFS file security permissions auditor", not "Cloud information assets security tool".

Describe a workflow or workflows from the perspective of your users. Not developers. Not architects. Not

This doesn't just apply to startups. I use a lot of Free Software, and many of these projects also fail to describe themselves clearly (though most, especially over time, eventually get it right, if only because other people can come in and rewrite idiotic descriptions). Reading through a list of package descriptions from Debian or Ubuntu, where a pithy, one-line description is your shingle to the world, should give a sense of good and bad descriptions.

Even long-established technologies such as Java suffer from this.

At www.java.com we have "What is Java?": "Java allows you to play online games, chat with people around the world, calculate your mortgage interest, and view images in 3D, just to name a few. It's also integral to the intranet applications and other e-business solutions that are the foundation of corporate computing." Um. OK. open http://www.java.com/en/download/whatis_java.jsp

At Oracle, we have a Java landing page with ... no description of the technology or its components (which aren't self-evident): http://www.oracle.com/technetwork/java/index.html

One of the best succinct summaries I've seen in recent memory is from jwz's "Java Sucks" page:

there are four completely different things that go by the name "Java": 1. A [programming] language, 2. An enormous class library, 3. A virtual machine, 4. A security model. http://www.jwz.org/doc/java.html

Now that is something I can wrap my head around (he also goes on to describe strengths and weaknesses of each component, good essay, read it, it's still disappointingly relevant).

Note though: the best product description comes from a critic. If you fail to clearly define yourself, your critics will.



You said to describe the product from the perspective of the user, not the developer, but then you preferred the developer description of Java (language, library, VM) over the user description (play games, chat with people, view images in 3D). It does seem like your average person landing on the Java page cares more about the second list. I mean, what the hell is a virtual machine anyway?


I'd say there should be two different pages: one for end-users, and one for developers. In his defense I'd argue the users of Java are developers, in which case they need to know specifically what it is. For end users who need it installed on their machines, the description should be "Java is a necessary plugin to make many of your favorite applications work correctly."

In the case of other tools, a lot of companies focus on useless buzzwords like "it's a cloud-enabled multi-tier architecture et cetera" instead of focusing on what the person using it cares about: "it's a content management system for blogs." OK, got it.


Seems to me that Java's users are developers. No non-developer will ever install Java by itself, they'll only install it because something else they're installing requires it.


Which Java are we talking about?

Again, as jwz noted, it's four things:

1. A programming language.

2. A class library.

3. A virtual machine.

4. A security model.

As a systems admin, I play mostly in 3, deploying, tuning, configuring, monitoring (to the extent that piss-poor Java tools allow any sort of monitoring -- want a dump of what's in memory? Sure ... let's just pause ALL activity on the VM for the next 25 minutes), troubleshooting, and patching/updating the VM.

I'm also concerned with the security model, within the parameters of my other system security concerns.

For the language and class libraries, it's largely ensuring that what my devs need and use is provisioned on our test, staging, and production hosts. There's also digging through some of the logging / crash / debug output to see if I can sort out what's wrong and fix it myself, or punt it over the wall to Engineering.

So no, it's not just developers.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: