Archive for the ‘Product Management’ Category
Startup Tip #2: Talk to people early, talk to people often
While, and more importantly before, you “release early, release often“, talk to your customers, advisors, and partners early and often. This is a great way to prevent yourself from building the wrong thing. Coding is hard, talking with people is easy. [Though, many engineers might argue the opposite. 🙂 ]
Customers: Pitch customers your ideas and get their feedback.
- Will they pay for the new product?
- Which features could they live without?
- Try to have a basic demo/walk-through so that everyone can see what you are thinking. White boarding works too.
- Be sure to talk to a decent number of potential clients; Early on, you don’t want to waste time building features that only one client will use (of course, eventually, you may want to do so for your biggest clients).
Advisors: You need a solid set of experts to bounce ideas off of. People who have been where you want to go. You would be surprised just how friendly and helpful people can be, especially when you give them a piece of equity. [I’d like to take a moment to thank David Brussin, Brian O’kelley, and Mike Nolet; These guys are fantastic advisors on the product / management side].
Strategic Partners: Be sure to get your partners on board with what you are doing. You don’t want to develop something only to find that you can’t get access to a critical relationship.
Vendors: If you can pay someone (a reasonable price) to supply a component of your system, don’t build it! Oh boy are you going to save time.
- Try to lease/pay monthly and avoid long term contracts off the bat; You may want to drop the vendor in a few months.
- Be very cautious though if you plan to rely on an early stage startup for something… they could shift their product focus and leave you stranded.
At Invite Media, we lost a year of work because we didn’t talk enough. We iterated in a bubble and essentially developed a product without talking to a significant sample of potential customers and critical partners. We finally did figure it out though and shifted the product to something customers wanted. Josh Kopelman compared our journey to a heat seeking missile. I must admin that initially, we even made the mistake of developing with a single client in mind. We lost time working on features that only a single client ever used.
Startup Tip #1: Measure, Monitor, Alert
I can’t stress enough the importance of good monitoring. At Invite Media, monitoring and alerting were indispensable. We monitored everything we could: server, business, and application metrics. We knew about problems long before they became serious.
Some sample questions you should be able to answer about your app:
- How many requests are we serving?
- How many failed requests are happening?
- How many exceptions, warnings, and errors occur per minute?
- What is our resource utilization per customer?
- What is our response time?
Here is sample graphite graph from our war console showing test campaigns from a few years back.
I recommend making a webpage that lists all your important graphs. Bonus points for having it constantly refresh on a big monitor for everyone to see (i.e. a “war console”).
Recommended Tools:
- Zenoss
- Standard monitoring and alerting software. Great for server level monitoring: disk, memory, server up/down. Its a bit tricky to learn.
- Pagerduty
- A useful tool in combination with a tool like zenoss to make sure that critical alerts get resolved. It enables “on-duty” rotations as well as escalation rules if alerts are not resolved in a fixed time period.
- Amazon CloudWatch (new) or Graphite
- Allows for easy, up to the minute, application and business level monitoring.
- Pingdom / Webmetrics / Gomez
- Easy way to monitor url up/down and response time. Pingdom is cheaper and best for up/down status of simple requests. Gomez & Webmetrics are good for response time monitoring of full pages. Besides just monitoring your own site, I recommend also including partner url’s in pingdom. This will help in debugging the root cause of latency on pages. Gomez is overpriced but, if your partners are using it, you have to use it. Otherwise, you won’t be able to isolate if a gomez datacenter is to blame instead of your service [yes, partners will blame Gomez issues on you unless you can prove otherwise].
You can’t keep an eye on everything all the time of course; Setting up lots of thresholds and alerts is also important. Zenoss allows for setting these up. A cron script will do the job on top of graphite.
I recommend breaking alerts into critical (must be fixed immediately) and non-critical (can wait until morning) subgroups. You can then set pagerduty to make sms & phone calls for the critical group and only send emails for the non-critical group.
Scott is an entrepreneur, startup advisor, and angel investor. He was VP Enterprise products @ Schrodinger and Co-Founder/CTO @ Invite Media (acquired by Google).
Scott Becker's Blog 