Archive for the 'Engineering' Category

Stage-Gate and software don’t mix

Published June 25, 2010 Engineering , Product Development , Small business , startup Leave a Comment
Tags: , , ,

I recently read this interesting article from Nielsen Wire on new product development for consumer packaged goods (CPG).  This article talks about how to realize the most revenue from new product development in the CPG space. Key takeaways:

  • Manage ideas loosely (have an innovation team live far, far away from headquarters with low involvement from senior staff)
  • Manage the process precisely (a formal Stage-Gate process is recommended)

I found myself scratching my head over how to translate these astounding insights to high tech new product development in a software startup or small business environment.  My take: they don’t translate.

I agree in principle with managing ideas loosely – no blue sky work can occur if every new idea is shot down by someone who is too concerned with the here and now.  But is it prudent to have a completely separate blue sky process in a startup when the entire startup needs to all march to the same tune?  This structure seems advisable only for corporations with a strong established business, which generates the revenue to fund the innovation process.  For pre-revenue or early revenue-bearing businesses, there is no separation between new product development and the business itself – they are one and the same.  A company like that hasn’t earned the right to send a team off to another city and go blue-sky on everybody else.

The second point made in the article, regarding tight management of process, is even less transferable.    Let’s take the application of Stage-Gate for an example.  Imagine managing web software development with a 2 week release cycle, where each release must go through the 5 typical gates:

  • Gate 1: initial screen (to decide whether the idea is worth pursuing)
  • Gate 2: approval to proceed to building a business case
  • Gate 3: approval to proceed to development
  • Gate 4: review outcome of development before going into QA
  • Gate 5: review outcome of QA, decide whether to release

“Absurd” is the only word that comes to mind.

I believe in only as much process as it takes to maximize efficiency and guarantee a high quality of output. (That is a whole lot more process than most entrepreneurs I work with are used to.  I can’t help it – if I am to execute I have to set up an efficient environment.)  I also believe in tailoring processes to suit the industry and nature of programs.  Different processes are established for different things.  You can’t apply a consumer electronics hardware development process naively to shrinkwrap software development, and you cannot apply shrinkwrap software development processes naively to web application development.

Stage-Gate can work for CPG and hardware development programs with a long turnaround time, but is completely inappropriate for fast turnaround programs and most software programs.   It behooves senior management to understand enough of the principles of Stage-Gate versus Agile or Mini-Waterfall so they can apply an appropriate level of oversight without bogging everybody down with inapplicable processes.

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.

Issued patents don’t represent innovation

Published June 2, 2010 Engineering , Product Development , Small business , startup Leave a Comment
Tags: , ,

Are patents symbols of innovation in this day and age?

My take: NO.

Today I went to the USPTO site on a whim to see whether I had any new issued patents (my last company had a huge patent portfolio with me as a co-inventor in over half of them.)   Lo and behold, 3 of them were newly issued.

This is gratifying since I got to update my issued patent list.  But it got me thinking about the whole system.

First of all, I should add that I do believe there is value in the patent system as a mechanism for startups and small companies to protect their core intellectual property, build an image as an innovator in their chosen domain, and shore up their valuation during fund raising activities.  Having mostly worked for startups with a hardware component, I have seen first hand how one can really monetize a strong patent portfolio and defend one’s position as a thought leader in the marketplace.

I agree with Brad Feld in general about the absurdity of software patents, but I believe

(a) novel hardware and human interface ideas are generally worth protecting,

(b) novel algorithms that deal with very complicated math/physics problems are generally worth protecting too (even if they are implemented in software).

That said, I have become increasingly disillusioned by the entire US Patent process as a way to protect and encourage innovation and invention.  Here are some anecdotes from my prior lives.

  • The US Patent Office allowed a patent application for which the WIPO (World Intellectual Property Organization)  found a piece of prior art it apparently read on.  We had to modify the claims for the WIPO filing and file an IDS (Information Disclosure Statement) with the US Patent Office about this new piece of prior art, which promptly issued the patent as is with no changes required in the claim set.
  • The US Patent Office once issued us a final rejection letter – with instructions on how to rewrite the claims and pay a fee so we can get it allowed in the next round.   (How’s that “final”?)
  • The US Patent Office let a few claims through which I believed was too broad to be defensible, and too nonspecific to protect the associated core technologies.  And I think some of them read on prior art.  This is, of course, our fault; we did a lousy job  on claims development.  Still, the fact that those claims came through said something about the due diligence that the patent examiner did NOT do.

It’s a fine theory that the patent process rewards novel inventions, but the reality is that the system is not equipped to tell the difference between a truly innovative idea and a truly pedestrian idea. Consequently, anyone with an adequate budget, a moderately articulate patent application, several years of patience, and substantial flexibility about the language of the claims can get their US patent application to eventually issue.  The only patents I’ve seen that aren’t issued are those that were abandoned due to lack of budget.

At this point, my personal opinion is that a strong patent portfolio is a business tool, and is fundamentally not correlated with whether a company owns any intellectual property of note, or has invented anything novel that is hard for competitors to imitate.   We pay to play in the high tech world and I suppose I have to be at peace with that.

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.

Where should product management live in an organization?

Published May 27, 2010 Engineering , Product Development , Product Management , Small business , leadership , startup 2 Comments
Tags: , , ,

I attended Product Camp in Boston over the weekend and the topic of where product management should live in an organization came up once again.  I had a blog post about this on my abandoned old blog, so I dragged it out and looked at it.  I realized I now agree with bits of it and disagree with other bits of it.

On the bits that I agree with, I continue to stand by my basic tenet:

Engineering and product management must be peers.

In my old blog post I went on to advocate that Product Management reports directly to senior staff as peers of Engineering and Marketing. I still think that’s the best possible structure.

However, the reality is that very few startup companies and small businesses are equipped to support this structure.  The CEO is typically terribly overloaded and is often not equipped to give the head of Product Management the support that he or she needs on a regular basis.

At the time I thought the next best thing would be to have Engineering and Product Management report into a Product organization which then reported to the CEO. With one more company and a couple more years of perspective behind me, I no longer believe this is practical for a small company. When the company has 20 or fewer people, 3 product execs is 1 exec too many. A much more practical solution is to have product management report into either Marketing (prefered) or Engineering (as a last resort).

It all depends on the people we have in a company and the skillsets they bring to the table. If Engineering has access to resources who are great at understanding customer / buyer needs and wants and can generate their own functional specification as a service to product management, then I think a more strategic product manager with substantial product marketing skills would make sense, and that person would work well in the Marketing organization. Conversely, if product strategy and roadmapping is well covered by other executives, and the need is for detailed product design and specification, then a technical product manager reporting to Engineering could work just fine.

I still believe Product Management should have a seat at the senior staff table together with Engineering and Marketing. But I think other less optimal structures can be made to work. The trick is to clearly define the role within the organization and make sure the product manager can succeed in their role.

From Personas to Functional Specifications

Published January 25, 2010 Customer research , Engineering , Product Development , Product Management , startup 1 Comment
Tags: , , ,

This is the second post in my Customer Research series.

Many people have asked me how persona work leads to product definition.   Here is my personal take.

In any new product development effort, we need to ask the following questions:

  1. What is the market segment I am shooting for, and is it big enough?
  2. Who am I making this product for?
  3. What are the problems that customers are trying to solve?
  4. How may our core competencies be applied to solve these problems?
  5. What are the product features that may deliver these solutions?
  6. What is the end user’s mainstream workflow, and what minimum feature set is necessary to service that workflow?
  7. How would the end user want these features to work for Version 1?
  8. What would the roadmap look like for future releases?

Item 1 is a market sizing and analysis exercise.  It is based on quantitative data from analyst reports and from internal market analysis.  It builds the business case for a new product, and helps establish a basis for interest that justifies further effort.

Items 2 and 3 are addressed by persona development.  I like to interview prospective customers in the environment they will be using the product in about their thoughts on the problems that the future product may address.  I listen between the lines and then derive the needs, wants and expectations of the prospective customers.

The key words are “prospective” and “expectations”.   Expectations are set by experiences, which is why you will get a different result if you interview existing customers of a previous-generation product, as opposed to prospective customers that represent your target market.

Item 4 is a cross functional discussion involving the product manager, the engineering lead, and a proxy for an archetypical end user in the sweet spot, representing the primary persona we are trying to target.   For instance, if the target user is a 65 year old, there should be an older person in the discussion to represent their point of view.

If the core competencies do not support a viable solution to the customers’ problems, the team would have to go back to Item 1 and rethink the target market and the business case.   Developing new core competencies is an engineering research activity that precedes product development.

Item 5 is about envisioning features that will deliver the solutions needed by end users, and Item 6 places them in the context of user workflows.   One is meaningless without the other.

At this point is generally a lively discussion with all the possible ways to serve up benefits to customers.   Rather than going around in circles in the office, I reach out to customers to get their feedback.  I employ a few techniques for this:

  • Get customer feedback with paper prototypes.  This can be done either as a round-table discussion (2-3 groups of 8-12 participants each) or remotely by phone on a one-on-one basis.  This should be done with both prospective customers and existing customers so we can get the full range of perspectives for people in the sweet spot and for early adopters. Results should be interpreted separately, of course.
  • Beta testing with hacked prototypes where feasible. This should run for 2-4 weeks with prospects AND existing customers with separated analysis of results for the two constituencies.
  • A product concept test for the new product, executed as an on-line survey to prospective customers only.
  • A comparative product concept test, pitting the proposed product against a control product, executed as an on-line survey to existing customers and prospective customers.

Once we get through 1-6, we will have a clear idea of what features ought to be included.  The next step, Item 7, addresses how those features should work.  I like focus groups for this detailed phase, but if budget doesn’t permit, we can cover this with informal round tables or virtual focus groups.  I like qualitative techniques for this because it is difficult to get into enough detail with quantitative techniques.

When we wrap up Item 7, we have nailed all the requirements and are ready to develop a Functional Specification for Version 1 of the new product. This should represent a minimum set of features that service the mainstream workflows of end users in the primary persona.  The product team can now execute on the new product.

The learnings from 1-7 will also feed Item 8 – roadmapping.  We will have a ready list of features that deliver secondary benefits, and we can tentatively bracket those into future releases.

This process can sound like a drag. It is not. It is simply a practical way to frame the challenge of understanding customer problems.  The whole thing can take anywhere from a few days to a few months, depending on how much the product team already knows about the market and the product, and the scope for the new product development effort.   A little thinking goes a long way here – much better to invest time up front than start development without a clear understanding of what one’s doing and why.

Add to DeliciousAdd to FaceBookAdd to StumbleUponAdd to Twitter

Contractors or permanent hires?

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

In this uncertain economy, a startup is often caught in a Catch 22 situation when it comes to staffing and team building.  What do you do when you have a lot of work now, but you cannot predict whether the work will be there in 6 or 12 months?

Nobody likes to let good people go.  A decision to take on a permanent new hire is not something I take lightly.  To avoid hiring on spec, a lot of people turn to hiring consultants or contractors to get the work done while mitigating risk.  The thinking is that we can plug the current need with contractors now without resulting in a long term bump in the company’s operating budget. If the work stays and there is budget for it, wonderful.  If not, no hard feelings – we simply part ways when the work goes away.

This method can work wonders, but I have seen it being taken too far.  This is particularly problematic if some specific and esoteric domain knowledge is required to build the product itself.  So the next time the company needs to get something done, they have to incur the learning curve all over again.

I believe in striving for balance between the conflicting needs of not over-hiring and not building core competencies. I like the following model:

  • Hire contractors with domain expertise to address specific and transient project needs
  • Hire excellent generalists to become permanent members of the team. Do temp-to-hire if possible so we can test-drive the relationship and make sure the team member will thrive in the company in the long run.
  • Have the contractors work with in-house staff to complete their projects.  The project is done as quickly as possible, the in-house staff is cross trained in a new area they are unfamiliar with, and the company gets to build up its core competencies. It’s a win-win situation.

How have you addressed this challenge in your company?

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!

Minimum Viable (Hardware) Product?

Published December 1, 2009 Engineering , Product Development , Product Management , startup Leave a Comment
Tags: ,

I’ve been thinking long and hard about how to apply lean startup techniques to hardware products.

After much head scratching, I have to conclude that you don’t.  It can’t be done.

There are several killer issues:

  • Manufacturing lead times
  • Regulatory approval – cost and lead time
  • Inventory

Let’s say you invested minimally, developed a great theory regarding your customers’ needs and wants, came up with a feature set, completed the design and negotiated a price for your tooling, all for peanuts.

Now you have to wait for your contract manufacturer to go through all the stages of their validation process to get to the beginning of the ramp for mass production.  That’s a couple months right there.

Once you have a pilot product to test, you will need to submit it for regulatory approval in all the countries you plan to sell the product in.  That’s a couple more months and tens of thousands of dollars of regulatory certification cost.

Then, mass production starts.  Capital is tied up in component cost.  Then you start churning units on the manufacturing line. More capital is tied up in finished goods.

By now, it’s been many months since the inception of this new product idea.   Finally you are able to sell your product to real buyers and users – and you find a fatal flaw, which you have missed in your haste to bring your product to market.

Guess what?  You can’t afford to write off the inventory. So your sales team will need to sell the flawed product as is.  If you are selling through retail channels, that’s even worse: you have to make sure they are incentivised to sell through to end users.  Suddenly, instead of spending your available capital on the next iteration of your product, you are now spending every available dollar on marketing in hopes of moving units out of inventory and freeing up cash.

So, much as I love the idea of lean startup techniques, I regretfully came to the conclusion that when it comes to hardware products, you have to do it old school.  Do your homework.  Make your business case.  Test, test and test some more using storyboards, white models, reference products and so forth,  without charging people money for it, and get buyers and users to be heavily involved during the product development process.  Validate and verify to the death.

There’s still opportunity to apply MVP principles: don’t overdesign, but whatever you do design into the product, do a kick-ass job.  A serious mistake may not be survivable for a small company introducing a new hardware product to market.

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.

Next Page »

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