Archive for the 'Software' Category

Rallying a team behind unsexy projects

Published June 3, 2010 Engineering , Product Development , Product Management , Small business , Software , leadership , startup Leave a Comment
Tags: , ,

It’s easy to get a team psyched and energized on sexy projects – the kind that have huge and visible customer impact, which gets your senior management and your board all excited.  Think of a software UI and workflow redesign that makes it ridiculously easy for your target end users to achieve their goals within your product, or a release of a new product with new and highly visible features.

It’s not as easy to get a team psyched and energized on highly strategic projects which, when done perfectly, has no visible manifestation whatsoever (except in subtle ways, such as improved performance of a software application, or a reduced incidence of rare catastrophic failures).  Think of architecture work, refactoring, server architecture rework for hosted applications, cost reduction exercises for existing products and so forth.  These sorts of projects are like plumbing: nobody notices the work if it is done right.

There are many ways to rally a team.  A steady stream of ongoing feedback and encouragement is a must.  Small victories should be celebrated as they come up.  I make sure my team is well fed if they have to work weird hours in support of some big initiative.  I like a little champagne to celebrate major milestones.  A private word of thanks and some token of appreciation is always appropriate as well.  But a much bigger part of it is public recognition of a job well done.

For jazzy projects, this is easy: everybody can see the end results and the quality and speed of execution of the work is self-evident.  For plumbing projects,  it’s much harder: even senior management often misses the magnitude of the achievement.  One could have a team toil for months on a huge project with everyone else scratching their heads on what this team achieved with all those man-hours.

In these cases, it is imperative that we explicitly call attention to the speed of execution and the quantity and quality of the work done by the team in a public manner, and make sure the team is recognized for excellence in execution.  We simply have to work harder to frame the achievement in a way that is immediately understandable by people outside the fray, so they can appreciate and applaud the contribution that the team made to the cause.

Conflict of interest

Published May 27, 2010 Engineering , Small business , Software , leadership , startup Leave a Comment
Tags: , ,

I recently ran into a conflict of interest scenario in two separate situations.

Situation 1 had product management pitched against engineering. Product management wanted to get more bug fixes into the next release. Engineering wanted to stop changing the code so SQA could actually finish what they were doing.  The issue? I was filling in for the product manager while serving as the head of engineering.   In the end, the conservative voice of engineering won, simply because we didn’t have the resources to run yet another full set of regression tests on a new deployment.  But I am not sure the best decision was made about the stuff we left out this go-around – maybe I could have made it work if someone else was there to push back on my decision.

Situation 2 had development pitched against SQA.  Development wanted to get a beta release out for field testing sooner than later, to hit an externally imposed deadline. SQA thought it was absurd, as the beta release hasn’t  been put through its paces in beta testing.   The issue? I was filling in for both development AND SQA.  I wrote the code myself and badly wanted to see it exercised in the field.   I ended up ceding the release decision to Sales (with predictable results – the beta release is now in field testing.)  In hindsight, I pretty much made the de-facto decision to release the beta build myself.  No sales organization I know would turn down a demo build with new features, as long as it looked like it worked at least once.   Just thinking about this makes me cringe.

My key takeaway is that no matter how short staffed we get, it is absolute lunacy to have the same person fill roles which are meant to check on each other.  It’s a recipe for bad decision making.  Better to let deliverables slide out in time than give up on the healthy tension that helps ensure a high quality of output.

I’m OK with the first decision, but I feel nauseous each time I think about the second. I hope to God that Murphy’s Law is kind to me just this once, and that nothing bad happens with my horrifically under-tested beta release.

Beta programs

Published February 22, 2010 Customer research , Product Development , Product Management , Small business , Software , startup 1 Comment
Tags: , , , ,

This is the eighth post in my Customer Research series.

What is a beta program? The Wikipedia has the following definition:

“Beta” is a nickname for software which has passed the alpha testing stage of development and has been released to users for software testing before its official release. It is the prototype of the software that is released to the public. Beta testing allows the software to undergo usability testing with users who provide feedback, so that any malfunctions these users find in the software can be reported to the developers and fixed. Beta software can be unstable and could cause crashes or data loss.

In my mind, the beta program provides an early window into how the market will receive the product release.  It generally happens at the very end of the development cycle.  I generally run small-scale beta programs as follows:

  • Recruit 10-20 beta testers to match the primary and secondary personas that the product is designed for
  • Do a kickoff meeting (either one on one or in a group) to set expectations on what’s in the new release, and how we expect to collect feedback from beta testers
  • Ask beta testers to use the product in the target environment of use
  • Schedule a call with each tester on the phone 1 week into the program, to ensure everything is going smoothly
  • Use phone calls and email to keep track of progress during the program
  • At the end of the beta program, schedule a phone conference or an in person debrief to collect feedback.

Since beta programs occur at the very end of the development cycle, typically weeks before the target release date, it is really only useful for testing things that can be iterated right before the release: positioning and messaging, delivery and support mechanisms and the like.  There is a great recent post on beta programs by Dave Daniels of Pragmatic Marketing that outlines all this – do take a look, it brings into sharp relief many of the questionable practices a lot of software companies take for granted.

Findings from beta programs can also be used to pull a release if (gasp!) a customer discovers a fatal bug that the QA department failed to find.  Lastly, it can also be used as a vehicle to collect customer feedback for the next release.  It is NOT a vehicle for usability testing – it is way too late in the game for that!  Usability studies (whether in lab or extended use tests) should be done early in the development cycle, before the product is finalized and when there is still time to effect change.

Using beta programs to test positioning is a great idea.  One can save a lot of money in marketing programs by iterating the messaging with target buyers until winning messages are arrived at.

Top smartphone articles from last week

Published February 21, 2010 Software , mobile Leave a Comment
Tags: , , , ,

Here are some smart phone articles I read last week. Enjoy!

General

iPhone / iPad

Google/ Android

Windows Mobile

Add to DeliciousAdd to DiggAdd to FaceBookAdd to RedditAdd to StumbleUponTweet this

Top 10 startup articles of the week

Published December 11, 2009 Engineering , Product Development , Product Management , Small business , Software , leadership , startup Leave a Comment
Tags: ,

Here are ten great startup articles from the past week. Enjoy!

10 Signs you aren’t developing a Minimum Viable Product

Published November 12, 2009 Engineering , Product Development , Product Management , Small business , Software , startup Leave a Comment
Tags: , , , , ,

10. You picked an embedded processor that yielded a firmware footprint headroom of 127% for future expandability.

9. Your firmware person often writes innovative features beyond what’s in the spec to harness some of that excess power in your processor.

8. Your product has a custom adaptor for an interchangeable component for which there is no alternative option.

7. You designed your PCB to be modular so you can plug different boards into the main board with nice flex cables. But you only ever sell the main board with the same module plugged in.

6. Your typical end user regularly uses only 7 out of 32 available user interface elements.

5. You invested heavily in a highly original feature that an end user championed. Upon investigation, he was one of 17 who cared  about this feature – out of 13,267 end users.

4. It’s hard to write a tutorial that exercises the full feature set, because 40% of your features don’t fit in the top 3-5 use cases.

3. You keep holding the release because someone keeps coming up with a last minute feature idea that really isn’t that hard to implement.

2. Your idea of product success is to solve some of the problems of all of the people out there, rather than solving all of the problems of some of the people out there.

1. It’s been 4 years since you proved the feasibility of your technology, yet your product is still in development.  And your product has nothing to do with curing cancer or sending humans to Mars.

Is this you? If so, you may want to read this seminal article on Minimum Viable Product by Eric Ries,  followed by this great article on the Minimum Viable Process by Cindy Alvarez. It may help make your product development cycle a little leaner the next time around.

How important is it for engineers to have direct access to customers?

Published November 7, 2009 Engineering , Product Development , Product Management , Small business , Software , startup Leave a Comment
Tags: , , ,

Today I attended Barbara Finer‘s excellent roundtable discussion on customer interactions at Product Camp Boston.  At one point, Barbara asked everybody to rate the importance of direct access to customers for product managers and for engineers.  Everybody agreed direct access for PM’s was extremely important.  However, the room was divided on the importance of engineers having direct access to customers.  One person rated it a 5 out of 10.

WHOA!

A few people, including myself, were up in arms over this.  I firmly believe we should have engineers meet and observe customers as much as possible, and as often as possible. In my 16 years of experience, this has never failed to make an impact.

To me, it’s an absolute no-brainer.  Engineers can get siloed unless product management makes it a point to provide them with context.  They need to be given the tools to understand how the features they are developing will be used, and why they matter to the company and its customers.  Nothing beats the immediacy of meeting customers and interacting with them.  It turns on the passion in engineers, and helps align them towards developing the right solutions to solve the customer’s problems.

Of course, budget and time is always an issue, especially in these lean times.  But if we believe this is important enough, we can certainly make it happen.  I currently have a budget for each engineer in my organization to travel to see a customer once a quarter. I’ll work fiercely to protect this budget to make sure my engineers are tuned in to the needs and wants of the customer,  instead of being tuned in to technology for technology’s sake.

Subscribe in a reader

Subscribe by Email

About Elaine Chen

I'm a 17-year veteran engineering and product management executive in the local Boston startup landscape. Click here to view my full profile.

Twitter Updates