Scott Friedman is a physician by training, an entrepreneur by choice, and a proponent of disruptive new technologies by avocation.  But, as Friedman has found, when you're building something that's never been built before and no one has ever had occasion to use, you need to work hard at keeping your goal in focus and articulating your product vision as simply and clearly as possible.  Otherwise your development staff can run amok without ever reaching the goal line. 

"The most important early audience is your own technical team because when you're making a new product or new product class, people can get into a lot of trouble if they don't have a very simple reference vision," Friedman observed.

Take for instance the material-handling robots that Seegrid, Friedman's current company, is building.  "If we had gotten into this saying that we're going to build a vision-guided robot, that would have been bad," he said. "Even though we had that enabling technology - a robust, vision-based navigation system - that's not the product.  And that was definitely not how we thought about what we were doing." 

So what, exactly, was it they were doing?  "We had this notion of what we called ‘walk-through-then-work.'  You could take this machine off a truck, walk it along a path in a customer's facility, and then it could repeat that path forever.  A very, very simple idea.  And having to adhere to that idea in the product management process made the technical decisions very easy."

Look past the technology

However getting to the point of articulating a short description for something nobody had ever seen before - one that focused on the result of the development process rather than on the enabling technology that brought it there - required considerable time and discipline.  The product's final depiction is one he attributes to his co-founder, CMU roboticist Hans Moravec.  "Even though he's the creator of the enabling technology, he very much articulated that product vision," Friedman said.  "It was based on his decades of experience building mobile robots and seeing what would fly and what wouldn't fly in the real world.  And over many years of living through what didn't work, he came to this kind of pared-down vision of what was probably going to work for regular customers." 

That's not so much the case with incremental product improvements, like refinements to cell phones, where the essential product is already well understood.  But breakthrough products are different.  "In new product development, when you're implementing, you're always coming across things that were unanticipated or you find out your MRDs were incomplete because it's an incremental process," he said.  "When you're creating something very disruptive that's not been done before, the chances are about nil that you're going to be able to think through all the use cases and all the scenarios before you start.  So having that kind of basic, simplistic, idea of 'this is what the product is supposed to be' allowed us very quickly to inform those decisions." 

Once the product idea has been articulated, however, it has to become internalized and eventually owned by everyone working on the project.  "People need to have their own reference image of what they're trying to get done," Friedman said.  "We very much try to clearly articulate it, and to do a good job on our Requirements documentation, but we know that ultimately that won't be sufficient.  At some point, somebody is going to have to make his or her own decision as to whether something is or is not in line with the product vision.  So we kind of set it up as a backstop for people." 

Delayed feedback

In Friedman's previous company, which developed enterprise software, product turnaround times were fast.  "At my last company we were always doing rapid prototypes and mockups and showing it to your end users and getting feedback," he recalled.  But in robotics, useful whole machine testing and feedback doesn't occur until the very end of what is typically a long development process.  Because of this, retaining that product vision is critical.  Friedman uses the analogy of rocket engineering.  "If you're building the space shuttle, you've spent billions of dollars and it's 99.8% complete, you look at it and it just sits on the launch pad and doesn't blast off.  You can test a part, but until the whole thing is done and built together, it's not going to take off.  Robotics has that same characteristic: you work for a very, very long time implementing subsystems and then doing integration.  But you don't see the whole thing move until years and years of work has been done.

Robotics feedback is also delayed because robots are physical, not virtual things. "The problem is that because robots are physical, you can't really get very good feedback until they're physically done.  Most customers can't stare at a picture and visualize how it would be to work with it physically - that's very, very hard to do.  So robotics has this characteristic: you have to work for a long time until you have something you can put in front of a customer to get feedback of any value.  And then they just might tell you that it's the dumbest thing, or that it's about a quarter of what they needed.  It's just because they're physical products and they're very hard to really understand any way but physically."  It's only at the complete terminus of your build do you even get to do the first thing, which is to actually get it in the field and get it in the customer's hands and see if it meets the need."

Stopping creep

To Friedman, having a simple product vision serves two other very practical purposes.  One is a trimming functionality around the core value statement.  "Think of Ikebana, Japanese flower arranging: it's not about how many flowers you put in the bouquet, but about how many flowers you can take away and still have a bouquet," he said.  "The other thing it does is to keep you from implementation creep.  I've seen many times where a team has an idea of what the end customers want, but by the time it all gets implemented, it's become a real cludge;  everyone on your team is happy.  But the customer, rather than being delighted, is confounded or, even worse, apathetic."

To some extent, sustaining a product vision through the entire development cycle is about being bull-headed.  But not entirely.  "It's more about carefully making sure that everybody understood why, even though it was a very simple vision he articulated, it would not be improved by adding five more features.  So generally, the shorter the description, the better it is," he said. 

"There's this saying: if you know not which you port you sail for, any wind will do," Friedman observed.  "I've seen a lot of tech companies where that happens.  They have some interesting technology, they kind of have an idea of where they're going, but then they get seduced into making something very general that can serve everyone.  But then it's mediocre.  That's one of the many ways you can fail in tech startups."