Advice for IT Startup Founders

Dharmesh Shah from Onstartups.com has some advice for IT Startups. I've pasted them below for your reading pleasure:


17 Pithy Insights For Startup Founders

1. Seek transparency and understanding with your partners early. Issues get harder as time passes

2. Startup founders work long hours for a reason. There’s more work than there are people. If you’re seeking balance, seek it elsewhere.

3. Bad customers will drain you of passion. Really bad customers will drain you of both passion and profits. Unfortunately, most bad customers will degenerate into really bad customers if you don’t do something about it.

4. If you’re changing direction often, worry a little. If you’re changing people often, worry a lot.

5. It’s lonely at the top, but even lonelier at the bottom. In the early days of a startup, hardly anyone wants to talk to you (except some desperate vendors).

6. Eventually, your product will need to work and do something useful. No amount of marketing or strategy will get you around this.

7. At the end of each day, ask yourself: “Did the product get better for customers today?”. If you don’t have a good answer, stay up until you do.

8. Until you are profitable, time is working against you. Once you are profitable, time is on your side.

9. Learn to take calculated risks. The market rarely rewards safe bets.

10. To improve the quality of your output, improve the quality if your inputs. Read, converse and connect with the right people.

11. Force yourself to write, as it will force you to think.

12. At least once every year or so, your startup will almost die.

13. The problem you solve should be ugly. The solution you build should be beautiful.

14. Even the most successful startup ideas had 100 reasons not to pursue them. There is no perfect idea.

15. If the pain doesn’t kill you, it just hurts a lot.

16. You choose your destiny, because you choose your team.

17. Be who you are. Do what you love. Join people you like.
    

Learn OpenID in 5 minutes!

Simon Willison has posted this screencast with a demonstration of how OpenID works. Nicely done. I wish there were one for Infocards. Then I could write a blog entry called "Learn Infocards in 5 minutes!" Kim? Is there already one?

What's this Role Management stuff about?

I read a press release today about a Role Management company called Vaau. Vaau first caught my attention back in March, when Gartner identified them as a "cool vendor". I'm sure the company name helped out, but the main reason for the honor seems to be the ability of their product RBACx to perform attestation at the user level rather than the role level (which seems like an obvious must-have for a role management product, although some "role management" vendors might disagree). Anyhow, today's press release was regarding a strategic partnership they struck with Sun. Seeing that there are more than a few vendors joining this space, I'd like write a few entries about the field, typical product features, general philosophies/approaches to role management, sushi and some of the vendors (off the top of my head, Eurekify, Bridgestream, Vaau, Courion, BHold, etc.).

The first place to start is what role management is all about. Using the latest technical jargon, a role is a grouping of things that need privileges to do stuff to other things. So it follows that role management is the management of what I just said. The main driver is usually all about access management, hence the term RBAC (role based access control). The idea is that its easier to manage roles as opposed to individual privileges. (Of course, compliance is a driver as well.) Sometimes that doesn't work out as planned. It's not unheard of for clients to complain that they ended up with more roles than people in their organization - which sort of defeats the purpose, especially if your role memberships are only people.
So the next post: typical product features in a role management app.

Become Rich: Use a Business Model!

I found this excellent blog yesterday by Alex Osterwalder. For those of you who are clueless (like me) - start here: What is a Business Model?
And find out why its important.
Then work your way to the Business Model Template.
Then use it to make very own.
Now the last and final step. Execute.

Why Use Cases Should Matter in Identity Deployments

In a comment to a previous blog entry, where I attempt to make the case for Use Cases in Identity Management integration efforts, James McGovern comments:

"First, many folks in the IDM space don't really understand how to create use-cases because it is not a traditional business-oriented scenario.

Second, the importance of getting a PM has to be not on internal nor external but someone who has walked the path before. This is pretty difficult to find even amongst the vendors themselves."

Focusing on his first point, I'd have to agree: use cases really come from the software engineering world (I believe originated from one of the three amigos - Jacobson). Wikipedia has a terse description of what a Use Case is:

In software engineering, a use case is a technique for capturing the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by software developers and end users.

In my opinion, the software engineering world has a lot to offer the identity integration world. Software engineers (and I use that term broadly) typically have a lot more interaction with business users than back-end integration folks. Figuring out how to efficiently produce software that the client wants/needs has been at the center of decades of discussions surrounding dev processes and methodologies. The integration community on the other hand are usually less focused on customer satisfaction, and more about making processes work efficiently and reliably. With the advent of identity integrations, the level of interaction with business development users has increased significantly. Many steps within the process of integrating an identity platform necessitates interaction with business users, such as mapping business processes and ultimately optimizing them (and the various touch points end users will have with it - for example in provisioning workflow), as well as user interaction with password management systems, esso, etc. I do agree that some components of an Identity platform may be invisible to the user, but typically the user will have at least indirect contact with it. (For example, in a metadirectory solution, a self-help name change in an HR data repository might result in a displayname change in their e-mail address or the name that appears on a phone handset.)

Identity integrators usually come over from sysadmin-type backgrounds, and (even those who have done an identity implementation or two) might not have the disciplines a software engineer would have in delivering a solution that the client is pleased with. (Even worse, many PMs for Identity projects that I've met don't seem to have much PM experience to begin with, or might be a sysadmin who successfully ran an exchange upgrade.) The result is what Mark Dixon described as the seven deadly risks, outlined below:

* Poor Pre-Project Preparation
* Poor Requirements Definition
* Large Initial Scope
* Inexperienced Resources
* Poor Project Methodology
* Scope Creep
* Not Using Available Support


The solution might lie in borrowing software engineering processes that would be helpful in initial preparation and scoping of an identity project, as well as ensuring that an iterative process results in happy business users.

To be continued...

Jackson Shaw is Blogging

Jackson Shaw from Quest is blogging. Jackson previously worked for Microsoft where he was Product Manager (I believe) of MIIS. Since then, he joined Vintela which was acquired by Quest. Quest now has its own portfolio of Identity products, ranging from the cool SSO stuff Vintela was doing between Unix and Windows, as well password management, audit tools (including what they call 'cross platform identity auditing' - which sounds really important), and provisioning.

Jackson's blog is self-described below:

Jackson's comments, commiserations, confabulations and simplifications on identity management and Microsoft's Active Directory all based on his continous "reality tour" of meetings with customers, ISVs and Microsoft.

Ok...so what does commiseration mean?

Definitions of commiseration on the Web:

a feeling of sympathy and sorrow for the misfortunes of others; "the blind are too often objects of pity"

condolence: an expression of sympathy with another's grief; "they sent their condolences"

Got it. Regardless, I think Jackson will have some pretty insightful blog entries regarding the identity topic. Go check him out here.