It's often said that most start-ups go through several pivots before they get to some form of market success. That pivot might be the product, its target audience, or the delivery (such as turning the product into a service). Such outward-facing effects change the way the company is seen by potential investors as well as customers, shaping the chance of success.
It is also almost always the case that there are internal pivots that shape what the company is, & what it looks like to itself (& to its board), & how it does business. Although multiple pivots can happen, there is usually only one that stands out in the history of the company - & I would like to christen it the "'This is Serious!' Moment" (TISM) in honour of a now-forgotten indie band of twenty years ago that had nothing to do with the rest of this article. This is separate from, but often related to the "Holy Cow!" moment (HCM) when things suddenly pivot for the better after a lot of hard work.
At some point, founders will gather in the garage or around the little table in the kitchenette of the office & know that, very soon, they won't be allowed to make world-shattering decisions by scrawling on the back of a bad printout, because everything they do is now more important. Often, this internal realisation is accompanied with a flurry of very corporate activity like hiring a CFO to actually be responsible for finances, or a project manager to guide releases - a layer of governance that doesn't sit well with a seat-of-the-pants operation, but is essential when things start to become serious.
Sometimes, you can miss the "This is serious!" moment because it happens immediately after the "Holy Cow! Someone gave us money!" moment (HCM), & that heady experience of losing your doubts over success - if only for a day or two - makes you miss the fact that, not only have you asked "What next?", but you always knew the answer - things get more serious.
Some companies seem to never grow up, never have a TISM - but it's always an internal moment, & almost always before the company goes public. You'll find that moment buried in the middle of biographies & exposés. It doesn't have much significance in itself, because every company does it, but no company that succeeds didn't do it. Google's TISM was probably hiring Omid Kordestani for sales. In the case of Microsoft, it was probably the move to Washington after successfully divorcing from MITS (eerie coincidence of letters).
Strive for the HCM, plan for the TISM. Don't get left wondering "What next?"
Wednesday, November 25, 2015
Continuous Improvement as a Business Transformation
One of the key benefits of an agile methodology like Scrum - & something that is very hard for a non-developer to get their head around - is that the methodology encourages & assumes some form of continuous improvement. There is regular reflection on the process as implemented, & how it can be made to work better.
Something that is much better understood at a corporate level than it is within an IT team is a business transformation process (or project), which sets the goal of achieving particular outcomes in some parts of the business as a result of a specific set of changes.
These are, more or less, equivalent.
Having said that, they are never seen as such for one very simple reason - one is iterative (usually based on a sprint of, say, two weeks), while the other is waterfall (lots of design up front, big delivery at the end of the project).
It is generally as a result of this divide that there are perceived differences like:
However, it will only add value if you can measure the outcomes. Anything that adds value can generally add the right kind of value (efficiency, cost reduction) if you set the right goals & measure the effectiveness of investment.
Too often, an IT unit "goes it alone" to improve itself because there is no executive buy-in for a business transformation process that is not a project that appears in an annual budget. Too often, executives see the internal workings of an IT unit as too arcane both for them & their board.
However, when the way that IT units work becomes the focus of a business strategy - with measurable outcomes - the business can only get better at measuring its own likelihood of success.
Something that is much better understood at a corporate level than it is within an IT team is a business transformation process (or project), which sets the goal of achieving particular outcomes in some parts of the business as a result of a specific set of changes.
These are, more or less, equivalent.
Having said that, they are never seen as such for one very simple reason - one is iterative (usually based on a sprint of, say, two weeks), while the other is waterfall (lots of design up front, big delivery at the end of the project).
It is generally as a result of this divide that there are perceived differences like:
- continuous improvement rarely plans ahead, setting goals against which they measure their progress in improving
- business transformations produce isolated results in unrelated projects
- continuous improvement produces a trend of live status which is often out of date as soon as you print it
- business transformation has success criteria defined that ensure that a project ends & its approved budget can be classified into accounting periods & closed off
However, it will only add value if you can measure the outcomes. Anything that adds value can generally add the right kind of value (efficiency, cost reduction) if you set the right goals & measure the effectiveness of investment.
Too often, an IT unit "goes it alone" to improve itself because there is no executive buy-in for a business transformation process that is not a project that appears in an annual budget. Too often, executives see the internal workings of an IT unit as too arcane both for them & their board.
However, when the way that IT units work becomes the focus of a business strategy - with measurable outcomes - the business can only get better at measuring its own likelihood of success.
Monday, November 23, 2015
Development Methodology as a Business Strategy
Although it may not be trendy, it is still often the case that people say that they follow an Agile methodology, but usually explain it in terms of how the product development process happens in isolation of the rest of the business.
Regardless of the flavour of agile, the implementation of the processes should - indeed, must - align with the business strategy. Without some alignment, there is nothing at C-level to indicate that the engineering department is effective, except in terms of project success rate or marketing meeting its goals. To have a measure of effectiveness within an engineering department, then there has to be something measurable at enough detail to make predictions, set goals, compare, & assess.
Agile processes generally provide a framework for being more effective at developing product. The processes themselves need to allow for reflection & adaptability in an iterative sense - continuous improvement. Even if board-level decisions are not agile, the benefits of agile processes can - & should - lead directly into corporate strategy.
To give a concrete example, the cost of an engineering department is usually considered to be linear against resources. However, it is "well known" that a more effective team produces better product (cheaper to maintain & support, easier/cheaper to extend, faster to react to market needs). If there is a company strategy for producing better product (with a goal of lowering maintenance costs), then the process for achieving this - improving the effectiveness of the development team - needs measurable goals.
Candidates for measures - from a product development perspective - might be:
Now we can understand why a strategy is never applied to a development methodology - it takes a lot of effort to translate the language used in engineering into the language used in business strategy. It is not impossible, it's just the few people are doing it.
The first step is always the hardest. A board has to have goals that cover both outward-facing measures (P&L) & inward-facing (team effectiveness), & these have to be aligned by strategies that inter-relate & support each other.
Regardless of the flavour of agile, the implementation of the processes should - indeed, must - align with the business strategy. Without some alignment, there is nothing at C-level to indicate that the engineering department is effective, except in terms of project success rate or marketing meeting its goals. To have a measure of effectiveness within an engineering department, then there has to be something measurable at enough detail to make predictions, set goals, compare, & assess.
Agile processes generally provide a framework for being more effective at developing product. The processes themselves need to allow for reflection & adaptability in an iterative sense - continuous improvement. Even if board-level decisions are not agile, the benefits of agile processes can - & should - lead directly into corporate strategy.
To give a concrete example, the cost of an engineering department is usually considered to be linear against resources. However, it is "well known" that a more effective team produces better product (cheaper to maintain & support, easier/cheaper to extend, faster to react to market needs). If there is a company strategy for producing better product (with a goal of lowering maintenance costs), then the process for achieving this - improving the effectiveness of the development team - needs measurable goals.
Candidates for measures - from a product development perspective - might be:
- amount of time spent on rework (cost of problems found in testing)
- amount of time spent on re-implementation (problems found n the field - more expensive)
- estimation accuracy (for features or projects) - not just coming under budget
- velocity - the amount of work the team can do in a time period
- technical debt (the likelihood that something could go horribly wrong over time)
- alignment of skills to needs (training, staff turnover)
- false economies (where a cheaper option costs more because of knock-on effects)
Now we can understand why a strategy is never applied to a development methodology - it takes a lot of effort to translate the language used in engineering into the language used in business strategy. It is not impossible, it's just the few people are doing it.
The first step is always the hardest. A board has to have goals that cover both outward-facing measures (P&L) & inward-facing (team effectiveness), & these have to be aligned by strategies that inter-relate & support each other.
Product Development Strategy
If your core business is developing (supporting, maintaining) a product (or service), then your corporate strategy is usually focused on marketing/sales-oriented measurable goals such as unit sales or licensing revenue (or chargeability ratio), market share (or growth), or ROI for projects.
Essentially, these relate to SMART goals because the outcomes are measurable, but often what contributes to these goals are less measurable strategies - or are not seen as strategies at a corporate level. Essentially, the various approaches for achieving these outcomes should be quantifiable & comparable & relate to the goal.
Let's work through some examples. If your goal is to increase licence revenue by 10%, then you have several possibilities:
To take each of these in turn; if you want to sell more licences to an existing customer, then the product must be structured in such a way that this is feasible - that is, there are feature modules, or else the licensing is seat or transaction based. Without a product strategy that delivers these capabilities, you cannot use this strategy.
To raise brand awareness, you can market the product to new targets, but this can only be effective with good brand reputation - an infrastructure around product support & product supportability that ensures that field issues are dealt with in product planning, & that the product (or service) is identifiable (& differentiable) within the market. This can only come about in the way in which the product is developed - both in terms of its feature set, & its deployment & use (or customer engagement model).
Thirdly, to increase the perceived value of the product, you have to have a product strategy that aims to provide something beyond new features - a step up in a product's applicability or usefulness. Even if intending to pass on the costs behind providing the product (for SasS), you have to build a product that can measure its own costs & report on them. This may sound obvious, but without a strategy in place, you have no way of aligning product development to the corporate goals.
Essentially, a product is only as good as what you build it to be, but a product strategy should be good enough to support the whole of the business' expectations. If your business is wholly dependent on the product, then product development strategy becomes a board-level concern.
Essentially, these relate to SMART goals because the outcomes are measurable, but often what contributes to these goals are less measurable strategies - or are not seen as strategies at a corporate level. Essentially, the various approaches for achieving these outcomes should be quantifiable & comparable & relate to the goal.
Let's work through some examples. If your goal is to increase licence revenue by 10%, then you have several possibilities:
- sell more licences in the current markets
- expand into new markets
- increase the licence fee
- sell more licences with existing relationships (cross-sell, in-sell)
- find more customers (raise brand awareness)
- justify a price increase (added value, price restructure/passing on costs)
To take each of these in turn; if you want to sell more licences to an existing customer, then the product must be structured in such a way that this is feasible - that is, there are feature modules, or else the licensing is seat or transaction based. Without a product strategy that delivers these capabilities, you cannot use this strategy.
To raise brand awareness, you can market the product to new targets, but this can only be effective with good brand reputation - an infrastructure around product support & product supportability that ensures that field issues are dealt with in product planning, & that the product (or service) is identifiable (& differentiable) within the market. This can only come about in the way in which the product is developed - both in terms of its feature set, & its deployment & use (or customer engagement model).
Thirdly, to increase the perceived value of the product, you have to have a product strategy that aims to provide something beyond new features - a step up in a product's applicability or usefulness. Even if intending to pass on the costs behind providing the product (for SasS), you have to build a product that can measure its own costs & report on them. This may sound obvious, but without a strategy in place, you have no way of aligning product development to the corporate goals.
Essentially, a product is only as good as what you build it to be, but a product strategy should be good enough to support the whole of the business' expectations. If your business is wholly dependent on the product, then product development strategy becomes a board-level concern.
Saturday, November 21, 2015
Top Level IT Strategy
When I started getting involved with business architects, I was excited, because I thought - this is it, this is what ties what I've been doing (product development) with what I haven't been doing (running a company).
Eyes bright with wonder & enlightenment, there is still the question: why hasn't someone gone down this path before? Why is it that we think of IT (in the broadest sense) as only a business unit that supports the implementation of a company strategy, in terms of technology, or else as a unit that supports a sales/marketing strategy, in terms of delivering products & services?
Why is there rarely a top level strategy that sees IT units as an implementation of board decisions in themselves? Let me give you some examples.
If you're a non-IT enterprise (manufacturing, services, utilities, ...) there is an understanding of the IT needs of the business supported by an enterprise architecture & a plan to implement changes to the IT infrastructure to support financial strategies (say). Is there, however, a strategy governing the infrastructure that the financial strategy must align with? If not, then, as is often the case, each new implementation is a distinct & unrelated solution to an isolated problem.
If you're an IT enterprise, then your strategies are often around the deliverables of engineering departments - product releases, product strategy to compete, etc, but are there processes within engineering that directly support those strategies? If so, how do you ensure that they align - that they have the measurable outcomes that you expect, from a business point of view, to support the objectives of the company?
The short answer is that, without some form of business architecture - an understanding of how your business functions & the inter-relatedness of all units that contribute to the company's success - then not only can you not measure the impact of strategic decisions, but it is much harder to define strategies.
Right now, you're in one of two camps - "Great, I need a business architecture - where can I get one?" or else "My company is too small for that kind of stuff". The next step is the same, regardless. If your company has strategies & expects them to be implemented, then you need a framework to ensure that they are - across the organisation. If you don't have a framework, then your strategies are written in the sand & you hope that you're above the high tide mark.
I'm not going to say what framework you need, or even whether it needs to be a formal one, but without an approach to your IT/engineering departments that incorporates decision making into company strategy, you have an unmitigated board-level risk to deal with.
Eyes bright with wonder & enlightenment, there is still the question: why hasn't someone gone down this path before? Why is it that we think of IT (in the broadest sense) as only a business unit that supports the implementation of a company strategy, in terms of technology, or else as a unit that supports a sales/marketing strategy, in terms of delivering products & services?
Why is there rarely a top level strategy that sees IT units as an implementation of board decisions in themselves? Let me give you some examples.
If you're a non-IT enterprise (manufacturing, services, utilities, ...) there is an understanding of the IT needs of the business supported by an enterprise architecture & a plan to implement changes to the IT infrastructure to support financial strategies (say). Is there, however, a strategy governing the infrastructure that the financial strategy must align with? If not, then, as is often the case, each new implementation is a distinct & unrelated solution to an isolated problem.
If you're an IT enterprise, then your strategies are often around the deliverables of engineering departments - product releases, product strategy to compete, etc, but are there processes within engineering that directly support those strategies? If so, how do you ensure that they align - that they have the measurable outcomes that you expect, from a business point of view, to support the objectives of the company?
The short answer is that, without some form of business architecture - an understanding of how your business functions & the inter-relatedness of all units that contribute to the company's success - then not only can you not measure the impact of strategic decisions, but it is much harder to define strategies.
Right now, you're in one of two camps - "Great, I need a business architecture - where can I get one?" or else "My company is too small for that kind of stuff". The next step is the same, regardless. If your company has strategies & expects them to be implemented, then you need a framework to ensure that they are - across the organisation. If you don't have a framework, then your strategies are written in the sand & you hope that you're above the high tide mark.
I'm not going to say what framework you need, or even whether it needs to be a formal one, but without an approach to your IT/engineering departments that incorporates decision making into company strategy, you have an unmitigated board-level risk to deal with.
Subscribe to:
Posts (Atom)