• Ferhan Bulca

    I am an executive leader and a serial intrapreneur focused on innovation and design thinking. My purpose in life is to create products and services that make the world a better place to live in.

    In the course of my career, I have developed a deep understanding and expertise on all aspects of technology commercialization and product/service development. As a result, I have built multi-million dollar businesses from the ground up.

    I am the creator and the Lead Instructor for Business Innovation Certificate Program at University of Toronto, School of Continuing Studies.

    I offer business consulting services and I am available as a speaker for private and public events.

    Watch my recent talk at Ashoka Canada's Changemakers event at University of Toronto on YouTube.

  • Consult with me on Maven
  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 300 other followers

Thoughts on “4 Steps to Becoming a Successful Intrapreneur”

4 Steps to Becoming a Successful Intrapreneur by Will Yakowicz is an interesting read. In my opinion, it accurately and efficiently summarizes four attributes of a successful intrapreneur.

I strongly agree with all four and will discuss two of them here:

#2 Know what you are willing to invest: This is an area I constantly remind those who take my program at University of Toronto. Personal investments include time, effort and resources, on the obvious side. It also includes personal credit (of which you have a limited amount) in your company. Loss of personal credit scares many but a successful intrapreneur looks at the potential credit he/she could earn if their idea is successful. Fear leads to inaction, opportunity fosters action.

#4 Just do it already: Larger organizations require lots of planning, collaboration, prioritization, and approvals to initiate projects. A successful intrapreneur knows how much to plan and when & how to act. Results speak louder than paper studies. Knowing how to fly under the radar and when to show off successful results is a critical skill for intrapreneurs.

I welcome your comments on my blog. Please share this posting if you find it helpful. If you have any questions, comments or thoughts, I would love to hear from you.

Five Steps to Technology Commercialization – Go-To-Market Strategy

This is the second posting in my series of “Five Steps to Technology Commercialization.” Earlier, I introduced a commercialization framework for new and innovative business development (click here to read it).

Similar to designing your business, this step needs to be completed before you embark on development. The key objectives of articulating your Go-To-Market Strategy are:

  • Articulate why your target market(s)  care about your product/service, i.e., your value proposition
    The importance of this step is obvious to many people but it is difficult to actually do it. Putting yourself in the shoes of your target customers and thinking like them require effort. It is not a do-it-yourself-at-your-spare-time activity.
  • Specify your market penetration strategy and articulate how you intend to do so
    Many people develop top-down market estimates, which look like this: “Global market is $X billion, my geographic target is $Y hundred million, I will capture very conservatively 1%, resulting in a $Z million market.” I’d rather see a bottom-up approach: “There are X thousand organizations that could use my product/service, each spends $Y on my product/service and takes D days to make their purchasing decisions. I am budgeting Z full-time-equivalent sales people in my financial forecast. As a result, I will target so-many dollars in my first, second and third years.” This approach helps you identify how you penetrate the market with realistic assumptions.  
  • Design your market penetration experiments to validate them
    Everything you have done so far is based on assumptions. Specify small, quick and cheap experiments to validate as many of them as possible early on. Some of these experiments can only be done when you have prototypes, some earlier. If you know who you will sell to and how they will buy (see earlier steps), you can design your validation experiments without ambiguity. 
  • Develop financial forecasts
    Financial forecasts help you in two ways:
    • Understand your cash flow situation – While you are creating your financial forecast, you are forced to make assumptions about your fixed and variable expenses. Write down your assumptions and monitor them when you move to later phases of commercialization.
    • Establish financial targets – Yes, your forecasts are just guesses but they also set targets for you. If you cannot generate the revenue you forecasted, you have to take action. If you do generate more revenue (fast growth), you need to take action. If your fixed or variable expenses are different from what you forecasted, you need to take action. I guess you understand what I am trying to say here. Your “estimates” become your targets in operations.

Here is how you achieve these objectives:

  1. Create industry map(s) for target markets and plan actions to penetrate them.
  2. Self and competitor analyses (tools like SWOT, Five-Forces help).
  3. Definition of product and process requirements for target markets. Product/service requirements and mapping those requirements to the key features that your target customers want/need.
  4. Validation of (1) & (2) through early proof of concepts & market contact.
  5. Pricing and marketing strategy. It is hard to get your pricing right the first time around. Think of it early on and check out market reaction.
  6. Financial forecast (3- to 5-year) model. It is best to prepare the first year monthly, the rest quarterly. Anything beyond year-three is a wild guess but do it now and modify when and if you ever make to your forth year.

I welcome your comments on my blog. Please share this posting if you find it helpful. If you have any questions, comments or thoughts, I would love to hear from you.

Real-Life Examples for my Commercialization Process

Innovation Factory in Hamilton published my blog post, where I discuss real-life development and commercialization examples for the Go-To-Market Strategy phase of my process.  The examples are from my personal experience, which helped me shape up my Commercialization Process. You may read the post here.

Hope you enjoy it.

How is this for a change? IT thinks business!

Until now, the role of IT (Information Technology) in organizations has been about fixing broken computers, managing user accounts and ensuring that new software is deployed to users without much headache. In a complex world of applications that did not like to talk to each other — even if they were provided by the same vendor — IT professionals stayed (really) busy doing nuts-and-bolts level work. Keeping users productive as applications evolved (translation: became complex) is a difficult job. Business pressures, like budget cuts and staff restrictions, add to these challenges.

However, things are changing and IT has two options:

  • Evolve and adapt
  • Cease to exist and leave room for new competencies

Gartner (www.gartner.com), an information technology research and advisory company, has been advocating that the role of IT has to change. Gartner analysts argue that IT has lost control, especially with the advent of cloud computing, and has to reclaim its place by becoming an internal services broker. What does this mean really?

In my opinion, it means one thing: start solving business problems by providing technology solutions that are easy to use. If you think about your daily routine, we all spend considerable time making the mental linkage between various pieces of software that only provide a portion of what we need. Why can they not all be integrated to provide all the information we need when we need it? It appears now that there is a trend toward providing just that: apps that are integrated to provide the information we need when we need it!

There are a number of companies, from blue chip organizations to start-ups, that are racing to provide an integrated app environment to users. For example, IBM released the following video Rethink IT – IBM Expert Integrated Systems on YouTube to talk about their bet on the integrated app world. A couple of other notable organizations are ThoughtWire (http://www.thoughtwire.com) in Toronto, Ontario, which focuses on making data easily available to users, and SnapLogic (http://www.snaplogic.com) in Silicon Valley, which is investing on providing an integration platform for cloud apps.

The evolution of integration technologies will mostly eliminate the need for IT functions as we know them today. IT organizations will need to put emphasis on understanding business needs of its users and upgrade skills to provide solutions to those needs in order to continue to add value.

I welcome your comments on my blog. If you have specific questions, please feel free to contact me at ferhan.bulca@intrascope.ca.

Innovation in the clouds

How cloud computing, mainly seen as a way to reduce IT costs, is likely to be a platform for widespread innovation across industries?

In their book, The Innovator’s DNA, Jeff Dyer, Hal Gregersen and Clayton Christensen reported the results of their eight-year study in which they “sought a richer understanding of disruptive innovators.” Their studies showed that innovative entrepreneurs and executives behaved similarly when discovering breakthrough ideas. The authors characterized these behaviors through five skills: Networking, Experimenting, Associating, Questioning and Observing.

It is my belief that cloud computing directly supports at least three of the five skills.

Networking: Innovators are in constant pursuit of ideas through a diverse network of individuals. They socialize and test ideas by talking to people who may radically different points of views. Their approach is in contrast to that of most organizations, which continue to block access to popular social networking sites. However, the same organizations recognize the value of information shared among those who need it in a timely manner. Cloud computing brings in the controls organizations look for while enabling users freely socialize with each other. It helps break down organizational and geographic borders and opens the door for new opportunities to collaborate with sister organizations and competitors. A recent example of this is a software that allows multiple companies to share one issue tracking system and collaborate behind the scenes while end-users experience seamless issue resolution.

Experimenting: Innovators are tireless experimenters. They try out ideas, pilot concepts and collect feedback as much and as early as possible. Failure is not a concern for them. As Edison put it, they do not fail, they find 10,000 ways something will not work.

It is almost too easy to experiment in the cloud. In the past, IT prototypes required large capital expenditures, infrastructure builds, and personnel. Now, one can buy whatever level of computing (one server or a super-computer) without any up-front investment and start using it within minutes. There is no need to estimate and budget for usage many months in advance. There is no need for time-consuming setups, personnel training, hardware/software maintenance, etc. Now, one can experiment almost as fast as one can come up with ideas.

Associating is the ability to create meaningful conclusions from seemingly unrelated matters. It is the ability to see something that is before our eyes but most (if not all) others fail to recognize because they do not make the associations.

The exponential growth of data does not make it any easier either. In addition to the excessive amount of data on the internet, most organizations have their proprietary data and information on different systems, which don’t typically connect with each other. Cloud computing, with its centralized and connected nature, makes bringing information together and distilling valuable knowledge so much easier by taking away one barrier: disconnected, incompatible systems.

I am leaving the other two skills the authors list, Questioning and Observing,  out of this article but I would be curious to hear your opinions about how cloud computing may help with questioning and observing.

What is “Systems Engineering in Commercial Organizations?”

Since I started implementing systems engineering processes and practices in commercial organizations, one of the standard questions I hear is…

So, what is this “systems engineering” anyway?

While each implementation has its nuances, the fundamental building blocks of commercial systems engineering are as follows:

  1. Requirements Development & Management (RD&M)
  2. Product Architecture
  3. Design & Development Management
  4. Integration
  5. Verification & Validation (V&V)

Now, let’s open up each of these building blocks a bit further.

Requirements Development & Management is where everything starts. Typically delays in commercial and government programs are attributed to poor RD&M. First, not all requirements are created equal and the organization’s product development needs determine the types and levels of requirements that should be part of their processes and practices. The most common types of requirements are:

  • User requirements
  • System-level technical requirements
  • Sub-system level technical requirements
  • Product life-cycle requirements

Second, the management of each type of requirement is different from one and other because their purposes are different. Similarly, within each group of requirements, there are differences in priority and importance.

Architecture definition is the highest level solution to the set of requirements. A good architecture definition clearly shows the main components of the solution, identifies primary technologies and clearly states the interfaces (both internal and external to the system to be developed). The architecture definition should define the system to designers and developers in an unambiguous way and represent the system in different ways to different disciplines. For example, a hardware designer would be mostly interested in the physical dimensions, volume, weight, so on so forth. On the other hand, the control software developer will look for state definitions, timing diagrams, and so on. The role of the architecture definition is to anchor the system definition while allowing designers and developers freedom to conduct their art and expertise.

Design & Development Management is the act of leading the design & development teams and ensuring that detail designs meet the system-level objectives. It is common for designers and developers to lose sight of the “big picture” when dealing with many challenges of design & development. Moreover, there will be decision points where initial requirements and allocations may need to be modified and re-allocated. These decisions are mainly made according to the impact of the change on the system, which the systems engineer is responsible for.

Integration happens at many levels, from integrating resistors, capacitors and ICs on a circuit board to integrating a new service to a global organization. Regardless, the goal of integration is the same: build something larger than the sum of its components. Each integration step directly links to a V&V step.

Verification & Validation: While many people use these words interchangeably,  they have two very distinct meanings. Using an old definition, “Verification is ensuring that the system is built right. Validation is ensuring that the right system is built.” The former is checking the sub-system and the system against technical requirements to find out whether or not the requirements are met (it is built right). The latter is the ultimate test; check it out with the intended customers and markets. Does it meet their needs? Are they willing to buy it? Did we build the right system?

Done right, systems engineering processes and practices drastically improve the effectiveness of product development organizations. Done wrongly, they are just another addition to processes, practices and tools, which will be overlooked and slow down the organization.

Is It So Difficult to Observe Some Basics of External Product Development?

A long-time client thought they had a very straightforward product development challenge ahead of them. They started a project over a year and half ago, expecting to finish in less than a year. The purpose of the project was to incorporate two existing products together to produce a new offering, whose value to the customers would be more than the sum of each component. One of the products to be incorporated is theirs, the other one is from an external partner.

The idea was great. The project implementation, however, was too optimistic. Shortly after the project started, I had a conversation with one of the directors of my client and pointed out the issues they may face if they tried to fast-forward a few basics of product development that involved external partners. He thought the team was on top of the situation and they had it under control.

Just recently, I received a phone call from him. The project had derailed, it was delayed way beyond its target date and the management had started to panic. With that, my involvement in the project started.

A quick observation of the status revealed that the following basics were violated:

  • No clear agreement between my client and the external company on the requirements from the external company. The existing agreement is very high level and can be interpreted in different ways. The external company is very accommodating and is willing to work the issues out, which makes the situation better. However, the lack of clear definition is creating extra work on both sides, delaying the project and incurring higher costs – Not a good thing!
  • There is no agreement on the verification of each company’s product to ensure the two will work together. Both parties verify as they go but the final verification can only be done at the full system level. This “big bang” approach is causing the teams miss issues until full integration and verification. At this stage, it is more difficult and costly to pinpoint the root cause and fix the issue.
  • A definition of “done” was missing. This caused the teams to spin their wheels, continuously adding yet another feature, just because they could. Without a commonly understood definition of project completion, the team was disengaged and internal disagreements emerged.
  • The client has an effective product development process, which provides a high level of guidance and empowers the team to make their own decisions. There are control points in place to ensure the quality and effectiveness of decisions. However, the process is taken for granted by the management. Its intent and tools are not well-understood by the team. With too much freedom but without a good understanding of the intent, some decisions led to unnecessary work and friction among the team members.
  • A small project team operated on “everybody does everything” principle. While this is fine in a small and high powered team as the one on this project, some clarity in responsibilities and accountabilities was still needed.

I spent my first week on the job to rectify the above five areas. The focus was on the definition of “done,” and clarifying the process and responsibility issues in the team. With those obstacles cleared, the next step was to specify a pragmatic approach to address the requirements and verification issues. Since the project has progressed to the point where everything can be verified at the system level, there is no point in retroactive sub-system verification. With the participation of the team, we specified the next steps in verification to meet the “done” state. This exercise helped the team to focus its efforts and energize to get it done. Next, we identified who was responsible for what and resolved differences of opinions, which mostly reflected personal preferences.

In short, the first week was challenging and very productive. Now, the team sees the light at the end of the tunnel and is motivated to get there. There are other challenges ahead of us to meet the objectives and we will take it one step at a time.

%d bloggers like this: