March 18th, 2012 05:53pm
Sean Murphy
I have been exploring the use of several analysis applications that could access my LinkedIn account, my twitter account, and my GMAIL account. They want to help me leverage private information that requires my account password.
So far so good, except that LinkedIn, Twitter, and Gmail don’t appear to have any provision for just granting read only access. So if I want to use one of these analytic services I also have to grant them the ability to update my LinkedIn profile, tweet using my identity, and send e-mail using my identity. I haven’t been comfortable allowing write access.
If there is a way to do this please leave a comment. The closest I have been able to come is to take advantage of a LinkedIn feature that allows me to create a private RSS feed for announcements that I receive from my connections.
Related
March 15th, 2012 05:46pm
Sean Murphy
“Product-market fit happens first in sub-segments. Understanding the core value proposition for hyper-sub-segmented markets is where you’ll find strong market signals. You can’t go big without winning small first.”
Brant Cooper “Don’t Think Big. There, I Said It.“
The principle of small wins is critical to winning the trust of enterprises prospects making them your customer and in penetrating new markets. We blogged about our approach in “Crossing the Chasm: Look for a Niche in a Lot of Pain” with a reformulate representation of Geoffrey Moore’s “bowling alley”:
Look for niche markets who are in a lot of pain. If people are in enough pain they will change their behavior and risk adopting something new. After entering niche markets, we can move technology up and out by using the ones in the most pain as reference case studies to the others. Also notice you start with the smallest niche market. This will allow you to make your early mistakes on a smaller market. It also buys you time and expertise to develop a whole product.
“You aspire to great things?
Begin with little ones.”
St. Augustine
March 12th, 2012 05:12pm
Sean Murphy
“In a small way, every talent acquisition poisons the well for future, bootstrapped startups. It erodes the confidence of users and potential customers. People put their company blog on Posterous, they add their business to GoWalla, they gave AdGrok a few hours of their time, etcetera, etcetera.
I’m not saying I would turn down the offer. But I fear the long-term effect of all these acqui-hires is my potential customers saying “No thanks. I doubt you geeks will be around in 18 months” when I market to them.”
Erik Dungan (HN: callmeed) on “Posterous Acquired by Twitter” HN Thread (bold added)
An acquisition hire means that the original service is shut down or turned into an open source project but no longer maintained by the founders. In a thread on the Google acquisition of AppJet (EtherPad) on Hacker News commenter pvg nicely summarized the moral hazards in the transaction:
Any early-adopter of a start-up product accepts the risk that the company behind the product might be unsuccessful. Customers like that bet, in part, on the notion that despite the statistically long odds, the company is making every conceivable effort to stay alive and succeed.
The ‘buyout-and-the-product-dies’-type exit introduces a sort of divided loyalty and misalignment between the goals of the founders and the goals of their customers – if you’re unsuccessful you might fail and we might suffer an abrupt service termination but at the same time, if you’re quite successful, we might also suffer an abrupt service termination.
My observation on HN at the time was based on the original announcement that the service would be shut down within 6 weeks.
If only they had interviewed at Google and joined the team they wanted to be on a year ago.
These transactions trade on the goodwill of early adopters. And they make it harder for other startups as potential early adopters start to assume that it’s better to wait for what Google releases instead of investing time in a product that will be scrapped either if the company fails or is successful and acquired.
[Given that many of the AppJet team came from Google] My point is that if they wanted to build their own company they should remain committed to the product they built, and find a better support model for current customers/users than shutting down without notice. I do not begrudge them making money at all.
But one reason that they have “millions of dollars worth of Google stock” is because they offered a service that people adopted and paid for. I think they have more of an obligation to customers and users than the initial announcement indicated and I worry that not taking better care of customers in the transition makes it hard for other startups.
Google ultimately relented and open sourced the code, with this announcement currently archived on etherpad.com )
Google recognizes the value of the EtherPad code base and has released the code as open source. For more information, see EtherPad project on Google Code & EtherPad discussion group
This open source release has already led to many efforts to foster further development and provide EtherPad-like services. If you are looking for a service based on the EtherPad software, or want to run your own EtherPad server, see the following links (not affiliated with Google, use at your own risk):
This is not an “aint it awful” post. It’s a suggestion to take care in the commitments that you make to customers, especially early customers who help you create your brand, so that you honor only honor the letter of any agreement but also the spirit. If the opportunity to solve customer problems does not get you up in the morning it’s unlikely that a “big bag of money” will let you move to a better lifetime.
More fundamentally, as I wrote in “Overnight Success”
- If you define success as making a lot of money quickly you should go into sales and cut out the middleman.
- You can buy one lottery ticket and make a lot of money. You can buy many lottery tickets every day of your life and never recover the cost of your lottery tickets.
- Most of the time the opportunity for “overnight success” is sold by folks who are interested in making a profit on your dreams without actually fulfilling them.
- Of all the sources of funds for an early stage venture, revenue is the most compelling demonstration of traction. Too many entrepreneurs view fund raising as an accomplishment in and of itself.
The challenge with a startup–like many other things in life–is that you need to integrate many different inputs, your own hopes and fears among them, and negotiate a working consensus with your co-founders, suppliers, partners, and customers to be successful.
Updated Tue-Mar-13 to fix link to
In a thread on the Google acquisition of AppJet (EtherPad)
h/t to Syed Naimath (
@SNaimath)
Related Post Wed-Mar-14 Reginald Braithwaite’s post “Dear Landlord” closing paragraphs:
If I move in, I’m committing my business to your place. I don’t want to read a six-page letter telling me what a great ride it’s been and how much fun you had building this place and how much you’re getting to sell out, and oh yes, the loading dock is open 24 hours to help me move my stuff the hell out before you bulldoze.
Architecture models often have these tiny plastic figurines that look like people walking around. If I’m supposed to move in before you sort out your “monetization strategy” and “exit plan,” This isn’t an office and I’m not a tenant. It’s a model of an office and you’re asking me to be the plastic figurine sitting at the foamcore desk.
March 11th, 2012 05:27pm
Sean Murphy
The first time I heard the word samizdat was at an ACT UP meeting. The term was applied to the vast stacks of photocopies that every member picked up on the way into the Monday-night meeting: treatment guidelines, drug studies, bureaucratic analyses, action plans, contact lists, and announcements of events ranging from performances and gallery openings to house parties and memorial services. This collection was never referred to as anything other than “the table” (even though it usually spread over two or three), a twelve- or eighteen-foot-long banquet of paper down both sides of which several hundred gay men and lesbians, nearly indistinguishable in their Doc Martens and Levi’s and sloganed T-shirts, bent their spiky or shaved heads and served themselves and one another with the ordered geniality of an Amish wedding. I was an intellectually pretentious but under-educated twenty-two-year-old who didn’t want to admit he was unfamiliar with a term that had the clear, clannish peal of jargon, the ignorance of which marked him out as neophyte or, worse, interloper. In fact I heard the word as “same-as-that,” which led me to think of it as an assertion of status: though these stapled stacks of paper, most written by people with no political background or scientific or journalistic training, lacked the credentials and durability of proper books, they were nevertheless the real library of AIDS, and the bound books that trickled out of traditional publishing houses were the table’s supplements rather than the other way around.
Dale Peck “Same-As-That” [PDF][registration required] Harpers March 2012
I spent the morning at the Pycon 2012 poster session. There were projects or products related to weather forecasting, data driven journalism, drug discovery, non-SQL databases, robots, data driven activism, open source volunteer enlistment and management, gridbeam, etc.. Running in the same convention hall as a job fair for python programmers. This enabling technology and related products and open source projects are being applied to engineering and scientific problems in a variety of industries and disciplines: defense, oil and gas, animation and movie making, financial analysis, pharma, and engineering.
Coupled with my experiences at Strata and Big Data Camp that I detailed in “A Picture is Worth a Thousand CPU Hours” it’s clear to me that high performance computing–databases, parallel algorithms and infrastructure, and visualization all in service of substantially more complex analysis–is in a very productive ferment. I think this goes well beyond the Hadoop centric cloud computing models that gained early prominence that I have focused on for the last four years o so:
The closest I have come to identifying a second waypoint–after Hadoop–for navigating this rapidly evolving landscape is Evangelos Simoudis‘ “Insight as a Service” formulation:
March 10th, 2012 05:08am
Sean Murphy
This originally appeared in my “Entrepreneurial Engineer” column in EETimes as “Linc Jepson’s 74ze leverages Russian and American engineering talent to persevere” on Jan-18-2011. I have added some additional hyperlinks in this version.
Linc Jepson studied Electrical Engineering at Tufts and after he graduated with his BSEE he was drawn to Silicon Valley’s technology boom in 1997. He worked as an RTL design engineer at several startups including Auravision, Broadlogic, and Believe and in 2002 he travelled to Eastern Europe for two years where he worked for a startup microprocessor company). He returned to Silicon Valley in 2004 to co-found 74ze, a design services firm that leverages Eastern European engineering talent. I sat down with him after a recent Bootstrappers Breakfast to learn more about his entrepreneurial journey; what follows is an edited transcript of our conversation with hyperlinks added for context.
Q: You have a broad base of experience, what kind of work do you enjoy?
I enjoy the fast-pace of small companies, where there is not only the opportunity but the necessity to do all kinds of work. And that work has an immediate and significant impact. Early in my career I was doing clean-slate development, performance research, upgrading and debugging modules of long-gone developers, verification, 3rd-party IP integration, you name it. I didn’t realize it at the time but it was great training for consulting.
Q: Why did you pick Eastern Europe when you left the Valley?
During the 2001 downturn in Silicon Valley I decided to indulge my wanderlust a bit and to get a better feel for the foreign labor market. I had previously worked with a team of engineers in India. I had studied Russian for about four years in high school and college and had a seedling of an idea in mind about starting a services company that would have a portion of its team abroad.
In 2002 I moved over to Minsk and then Moscow for about two years. I brushed up on–OK I greatly improved on–my Russian and found a job doing RTL design in Zelenograd, Russia. Interestingly, the company had been founded by Chinese/Malay investors. I created a CompactFlash controller and a touchscreen interface. I was also making contacts and continuing to think about an outsourcing team.
I had confirmed that there is some exceptional talent there.
Q: How did you decide on outsource engineering as a business model?
We consider 74ze (pronounced 74 Zee) a services firm, first and foremost. We happen to use remote experts when it benefits a project. About a third of our projects never utilize our remote team. In school I studied International Relations as well, for a BA. Working with remote teams allows me to pursue another passion.
While I wasn’t keen on the mercenary perception that many folks have of contract engineers, I knew that there could be improvements made in the outsourcing model. Specifically, most engineers tend to shy-away from verbal or face-to-face communication. It seems easier to be non-confrontational and swap a few emails instead of picking the phone or Skype, but you can delude yourself into thinking that all will be okay. This can be particularly dangerous when you are an outsider of a company. These communication issues are often compounded by cultural issues. Merge a few factors such as a contractor being foreign and also more junior than the client’s counterpart, as is often the case with remote teams, and you often find someone who too often will dodge asking a short, potentially embarrassing question, and try to compensate by putting in more hours.
The fallout from labor globalization can be overcome with stronger communication and more global management experience. It’s not achievable in all stages of development, but someone who work effectively not only with other engineers in the same building but also with engineers in Krakow or Kiev is growing in value.
Q: How did you get started?
In 2004 I moved back to the US. We incorporated 74ze in Delaware, and then in Russia a few years later, after we had traction. One of our first two jobs was a local one. We had 2-3 people, all US citizens, on site. We only did minor work abroad, such as some analog modeling. The other early job was for a company in Europe. The job was a referral from an existing relationship. That job was done completely remotely. We only met the technical people from the client at a trade show, a few months later, where they demonstrated with our product.
Q: If you are doing RTL design and verification what EDA tools do you use?
An immediate obstacle that we ran in to when we started was the high cost of EDA tools. Right off the bat, this started knocking us out of the running for various contracts. When I was living in Zelenograd, I had used Aldec’s HDL verification tools and had a very good experience with them. After not using them for a few years, because we were using customer tools in the US, one of the guys on our team proposed that we incorporate Aldec’s tools into our next bid.
Over the years, we’ve built up a relationship with Aldec and have grown to rely on their tools quite a bit. It’s unfortunate that we didn’t get much traction in conversations with the other EDA vendors, but I think that we have found a good solution with Aldec Riviera-PRO and a solid partner for moving forward.
Q: Can you give me a brief overview of where the company is today?
We’ve shifted more towards verification in the last few years, both in terms of the jobs we’ve taken and also in terms of a conscious decision to solidify our roots in that space. While most of our early jobs were in or involved some design, and we continue to work in this field, we see that the continuing abstraction of testing is creating a very large opportunity. We’ve been honing our SystemVerilog skills in the last few years and have been doing more verification than anything else, lately.
While we are still a mix of full-time and contract-based engineers, we are a pure engineering team with next to no marketing or sales overhead. This means less overhead cost for the client, but also that we don’t have the sheen of the larger companies. When we meet with a prospective client, they meet the lead engineer in the first meeting.
The economy interfered with our plan to cycle a few younger engineers into our team. Our team has a minimum of 12 years of experience, but I expect that we’ll have an internal project running as a testing ground for some junior engineers later this year.
Q: What are the two or three things that you have been able to accomplish that you take the most pride in or satisfaction from?
We increased our role significantly with two clients over a 2-3 year relationship. With one of those companies, we joined to develop a few blocks from spec and ultimately took on a much larger amount of design work as well as key roles in integration and top-level verification. We helped carry them through full chip functional sign-off and final timing closure. The chip worked the first time. The CTO of one of those companies, Mark Indovina, became an advisor.
We nailed the deadline to get a prototype RTL processor core developed for another client, enabling them to meet the deadline for a multi-day meeting with one of their key clients in Japan. We had to make two flavors, optimizing for power and performance constraints.
I am happy that we have grown to the point where it made sense to incorporate in Russia; growing our team there was a significant milestone.
Q: What has been the biggest surprise? What was one key assumption you made, perhaps even unconsciously, that has caused the most grief?
Sales. Selling is tough. I came back from Eastern Europe and a bit arrogantly thought that as a skilled group of engineers, we would break into the contractor market easily. I have learned that selling is a process. I am not a salesperson in the least. My father was and I didn’t have much respect for the field, until I tried it.
Q: What development, event, or new understanding since you started has had the most impact on your original plan? How has your plan changed in response?
I thought that I would be spending a lot more time in Eastern Europe than I have been. We have a senior team there that runs smoothly. The last time I was there I was trying to hire another engineer for a project and was unsuccessful. Salaries were skyrocketing.
We are more local and on-site and less offshore-centric today than I initially envisioned.
Q: What suggestions do you have for entrepreneurs?
Be willing to deviate from your plan; not necessarily from your objective. I think we can (I did) envision the future too much or too specifically, such that you have a hardened mold in your mind and of how something will turn out and then work like hell to fill that mold with your progress. Sometimes there is less resistance to your goal down a parallel path.
Q: Thanks for your time.
Linc Jepson is a long time attendee at
Bootstrapper Breakfasts®, and has a brief video interview up at “
Linc Jepson: the main reason I come to the Bootstrapper Breakfast“
March 8th, 2012 04:33pm
Sean Murphy
“Unhappy users in our industry don’t continue to file bug reports; they start writing business plans.”
Michael “Mac” McNamara talking about the EDA Industry
I was reminded of this remark that Mac made at an SDForum event several years ago as I was reading the “Who Are User Entrepreneurs?” study which summarizes findings on innovation, founder characteristics, and firm characteristics released in February of 2012. I was alerted to it by a press release from Kauffman released yesterday “Nearly Half of Innovative U.S. Startups Are Founded by ‘User Entrepreneurs‘”
Here are some interesting passages from the study, with some further commentary mixed in.
What is User Entrepreneurship? User entrepreneurship is defined as the commercialization of a new product and/or service by an individual or group of individuals who are also innovative users of that product and/or service. A user entrepreneur tends to experience a need in her life and develop a product or service to address this need, often before founding a firm. As a result, user entrepreneurs are distinct from other types of entrepreneurs in that they have personal experience with a product or service that sparked innovative activity and in that they derive benefit through use in addition to financial benefit from commercialization.
I would suspect that these entrepreneurs bring domain knowledge and often an ability to offer differentiated services based on their own inventions allowing them to bootstrap.
We find key differences among users who founded firms around innovations meant for use in a previous job or business (professional-user entrepreneurs) and users who founded firms around innovations meant for personal use (end user entrepreneurs). [...]
The differences may have as much to do with education and socio-economic background and the causality may run in the other direction.
Professional-user entrepreneurs appear to have more experience along a number of dimensions than do other entrepreneurs in both the full sample of firms and the subset of firms conducting R&D in their first year of operations. Although the founders are, on average, the same age, they report higher educational attainment and more years of industry work experience, are more likely to have founded a firm before, and are more likely to have founded a firm in the same industry before. Their firms are less likely to be founded at home, less reliant on self-financing, more likely to receive venture capital financing, more likely to have revenues— and, among firms with revenues—generate higher revenues and are more likely to possess patents and trademarks than both the full sample and subset of firms conducting R&D. [...]
There are certainly many “change agents” who improve the robustness and viability of the firms they work at (but didn’t found). Also called intrapreneurs or bricoleurs. These folks may set out on their own to start a new company as well.
End-user entrepreneurs appear to have a demographic profile distinct from the full sample of firms and the subset of firms conducting R&D in their first year of operations. End-user entrepreneurs are more likely to be members of minority groups: they are more likely to be female; more likely to be American Indian, Alaskan Native, or Black; and less likely to be Asian. Their firms employ fewer workers, have lower revenues, are more likely to be founded at home and operate from home five years after founding, are more heavily self-financed five years after founding, are less likely to receive bank financing, and are more likely to possess patents than are entrepreneurs in the full sample and subset of firms conducting R&D.
What are the implications
- In fast moving fields, especially when you are selling to businesses, good user relationships are essential for encouraging enhancement suggestions that are viable and , if ignored, will lead to new competitors springing up.
- The harvest of insights from early users can be as important as the revenue and the testimonials a business relationship generates.
- Delivering the initial version of your product as a service looks like it may be a marker for success. Other techniques for “selling the result” instead of the product may be equally potent (e.g. selling the holes in the wall where the customer wants them instead of selling a drill).
March 7th, 2012 02:04pm
Sean Murphy
Last week was a thought provoking one for me with Big Data Camp on Mon February 27, a “Great Demo” workshop on February 29, and a tour of the Strata 2012 exhibit hall on March 1. I encountered either examples or stories of visualizations that required hundreds to thousands of CPU hours to create at all three events.
Thanks to the commodization that cloud computing is now driving you can spend $100 and get 1,000 CPU hours, the equivalent of a dozen racks of computers in a data center for a day depending upon how many chips and cores you can fit usefully into an enclosure. It’s roughly equivalent to running one computer for a six weeks to get an answer.
A lot of these visualizations involve streaming data, realtime processing, or graph calculations where one size does not fit all: SQL and Hadoop are not going to be the pervasive computing building blocks. I think we are in for a period of intense experimentation and search for new technologies (or perhaps old algorithms that can be given the computing horsepower they need to get rapid solutions.
A lot of weird new data stores, visualization techniques, and parallel processing methodologies are going to find problem architecture niches and become familiar tools in the next few years.
“When the going gets weird, the weird turn pro.”
Hunter S. Thompson
Three questions for those playing the home game:
- What’s the strangest useful visualization you have seen in the last year?
- What picture is worth a thousand CPU hours–or about $100 at a dime an hour on Amazon–to you?
- What models for “Insight as a Service” do you see emerging?
March 6th, 2012 06:03am
Sean Murphy
Pages 39-40 of “Pretotype It” (Second Edition) by Alberto Savoia lists seven techniques for determining that you are “building the right product before you invest in building your product right.” Bold text is from the book, my comments are mixed in below each one.
- The Mechanical Turk – Replace complex and expensive computers or machines with human beings.
Also known as
- starting with a service
- wrapping a thick protective blanket of consulting around your product so that no one is hurt by it
- selling the holes not the drill
- Wizard of Oz (pay no attention to the man behind the curtain).
- Flintstoning (Fred Flinstone’s feet powered his “car”).
- Manualating (a backward formation from automating)
- the concierge method
- The Pinocchio – Build a non-functional, “lifeless”, version of the product.
Useful for form and fit validation. Jeff Hawkins famously carried around a block of wood to get an appreciation for what a PDA might feel like.
- The Minimum Viable Product (or Stripped Tease) – Create a functional version of the product, but stripped down to its most basic functionality.
A basic approach for any bootstrapper – make sure you have the simplest offering that customers are willing to buy before you worry about adding features (and delaying time to break even revenue). In reading this Savoia is using the Marty Cagan MVP model “smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available – also known as valuable, usable and feasible.”
- The Provincial – Before launching world-wide, run a test on a very small sample.
Start in a niche. When in doubt zoom in or traction.
- The Fake Door – Create a fake “entry” for a product that doesn’t yet exist in any form.
I am not a fan of this except in very limited circumstances for B2B markets as it can be very corrosive to the trust required to built a long term business relationship. And at least with software products for business, a longer term relationship is normally intrinsic to the customer’s calculation of the value of your offering. If you start to erect “Potemkin village” products that have too many false fronts or facade items in your menus and options prospects may doubt the entire offering.
- The Pretend-to-Own – Before investing in buying whatever you need for your product, rent or borrow it first.
Find a way to use tooling or equipment before committing to a significant purchase.
- The Re-label – Put a different label on an existing product that looks like the product you want to create.
Often a more complex product can have menu items deleted or entire branches of a menu tree pruned to explore whether this is a market for a simpler offering. At Cisco we didn’t stuff two connectors on a four port router and changed the paint job to create a “lower cost” model until the box could be re-designed.
What’s missing
- The holodeck – simulate the effect of a product on a workflow: understand where the next bottleneck is to determine how much benefit eliminating one or more steps (or reducing one or more category of error) will actually yield. This is the default method for “system on a chip” design approaches but I suspect we will see more service workflow simulations as a part of the development of new service offerings in the future.
- Family Tree – verify that manual implementations exist for what you plan to automate, has someone written an Excel macro (or an EMACS macro) to solve the problem. Are people already following a checklist to prevent a category of errors? Replacing workarounds involves less behavior change (at least in terms of a customer’s view of the real problem) than getting them to try something without antecedents.
- “What’s On Your Mind” – understand the customer’s view of the problem and the constraints your solution has to satisfy before proposing one. This normally requires an active curiosity about the customer’s perception of their needs. This is not the same as asking them for features and implementing them without considering the deeper implications.
- Picnic in the Graveyard – do research on what’s been tried and failed. Many near misses have two out of three values in a feature set combination correct (some just have too many features and it’s less a matter of changing features than deleting a few). If you are going to introduce something that’s “been tried before” be clear in your own mind of what’s different about it and why it will make a difference to your customer.
- Want Ad – ask customers to write up a job description with a focus on “results to be achieved” by your product. Clayton Christensen calls this the “jobs to be done” model for a new produce (See also Chapter 3 from Innovator’s Solution “What Products Will Customers Want to Buy“
March 5th, 2012 10:06pm
Sean Murphy
“So I think it’s still a long time before we’ll have a building code for software.”
Rich Skrenta “There is no building code for software”
A building code is a function of the municipality issuing building permits for what is essentially custom construction. Products (and product liability calculations) are driven by tort liability, which is managed by insurance and mechanisms like Underwriters Laboratory testing and certification. It’s also managed at a Federal and state level by legislation
Even though most software licenses have strong limits on any warranty or liability I suspect that we will see both insurance-driven and legislative “design codes” imposed on software as it becomes as woven into the fabric of our lives as wood and sheetrock. The “software content” of not only airplanes but automobiles, power tools, appliances, and many other products is increasing each year.
Traditions are solutions to problems that we forgot we had. Most of the building codes are “rules of thumb” to prevent injury or loss of life, hardwired into legal mechanisms to prevent folks from cutting corners to save money and imposing a downstream risk.
Rich Skrenta is probably right that it will be a while before application software becomes subject to “building codes” but embedded software, and not just for medical implants and airplanes, may transition in a matter of a decade or two.
Two good books that bear at least tangentially on this topic are “How Buildings Learn: What Happens After They are Built” by Stewart Brand and “House” by Tracy Kidder (also author of “Soul of the New Machine“). Kidder offers a number of examples for why it’s hard to develop an innovative design for a house that is actually livable.
March 4th, 2012 04:39pm
Sean Murphy
“…visual thinking is a mandatory literacy for innovation leaders of the future.”
Lisa Solomon (@lisakaysolomon) in “The Visual Thinking Revolution is Here“
I have never considered myself an artist or visual thinker because I am not able to sketch a likeness of a person or draw a landscape. I managed engineers and drafters who had to produce mechanical and dimensioned drawings when I was at Cisco and 3Com, but I never had an affinity for the three dimensional visualization skills that they had.
I enjoyed reading “Back of the Napkin” by Dan Roam and covered it in our very first Book Club for Business Impact webinar last May. I found “Orbiting the Giant Hairball” by Gordon Mackenzie as very useful both for his visual metaphors and his advice for corporate change agents; I read it in 1999 after I had returned to Cisco for a second tour of duty and took away a number of insights. I also found “The Artist’s Way at Work: Riding the Dragon” Mark Bryan, Julia Cameron, and Catherine Allen very helpful, in particular the morning pages model (see “Maintaining Perspective on the Entrepreneurial Roller Coaster“).
I associate art with an effort to represent physical reality or inspire an emotional reaction to reality. It’s odd how you can put things in buckets and ignore them, I had discounted the “design thinking” model because art seemed to me to be less about business and more about self-discovery. And yet I have worked on teams designing very complex systems, the silicon cathedrals of the late 20th century, for the better part of two decades.
I am not sure why I experienced the dichotomy between system design and user experience design, although one presentation that helped me to crystallize my discomfort was Giff Constable’s “The Missing Agile Principle.” Reading it I realized that I was focused more on prospect/customer value and than the creative expression of an idea. Obviously you need both.
But I had an epiphany reading through the curriculum for the Design Strategy MBA offered by the California College of the Arts that I am actually a visual thinker: I can sketch a likeness of a business concept or draw a business process and do so all of the time. And where cycle time, people time, investment dollars, or data are the units of measure I find it easy to dimension my drawings.
I think we need better processes (and perhaps a better visual language) for sketching hypothetical business models. I think that useful likenesses can be found in Dan Roam’s techniques and perhaps some of the directed graph models that Brant Cooper sketches in “The CustDev Whiteboard.”
Watching electrical engineers develop new circuit designs I would see them sketch a number of different but equally useful diagrams that represented different aspects of a hypothetical design’s behavior or structure: circuit diagrams, waveforms, state machine diagrams, logic schematics, block diagrams, etc.. The “Innovator’s DNA” stresses the value of sketching timelines, workflows, and input/output diagrams to better understand the current situation and how it came to be. I think we can learn a lot from other fields for how to sketch the likeness of our hypothetical businesses and emerging markets.
Note: As to why I am reading degree curriculum and syllabus documents, I am not considering going back to college. I was researching what design thinking is all about after Lisa Solomon reached out to me in response to “Associating, Pattern Matching, and Sensemaking“)
Next Posts
Previous Posts