DCSIMG
Product Readiness
New Year, New Ideas – UNVC and Triple Jump Technology Event

First I wish a Happy New Year to all.

And now to business; during 2009 we are facing growing challenges with the economical downturn that require a new way of thinking for the short to medium term.

 We at Triple Jump Technologies have been posting regularly on sales and marketing focus aligned with and to product readiness. We also have been hammering on about partnerships to bring forward the positive opportunities being created by the new economical order. So together with UNVC we strongly believe we have an interesting vehicle to provide a different view point for Start-ups wishing to hear and discuss about business planning, sales and marketing path and planning with a view to expand to the UK and South Africa.

If you are a start-up and you are interested in joining this unique opportunity please contact us on sarit@triplejumptech.com

2009 credit crunch - implications on the product lifecycle

My last post dealt with the impact of the credit crunch on our organizations and specifically the Sales organization.
A short recap – we need to adapt a focused sales strategy to fewer markets which poses higher potential returns. More than that, I believe that more and more we will rely on channels and local agents to minimize the financial exposure of delivering sales in these markets.

On the other hand, the impact on the product team is to have the methodology and tools to quickly adapt the product to new requirements that may arise from shifts in the sales strategies. These product changes may or may not be needed but we need to be ready. I feel also that we may need to “compress” our product development lifecycle and roadmap to shorter timelines in order to achieve more robust products in a quicker time. So developing product agility and ability to be adapted quickly is a big a milestone to hit in your organization. More than that the product organization needs to be agile and have the processes to adapt to the changing technology and business landscapes.

As always an example – We were selling a consumer electronic product which had a keyboard in it. Historically the biggest customer was a German one and in Germany the keyboard is QWERTZ and not QWERTY (Y and Z change places). Sales in Germany slowed and we needed to convert the product to an English version, both software and hardware due to a sales opportunity in an English speaking country. The software part was easy as we had an English version but obtaining the QWERTY keyboards and retrofitting existing stock was a lengthy process which resulted in a big contract lost due to this delay. Product and mainly logistic agility were neglected over time which impacted the ability to change quickly.

I know that shortening production time usually equates to higher costs, but if an organization is saving money on a more efficient sales organization (our previous blog post) then funds can be diverted to meet needs in product development. So if we do things right we will retain the same if not smaller budgets while advancing our competitive capabilities a few strides forward.

So what is needed - Bottom line:
Sales – refocus and get efficient otherwise we’ll drain the cash from the piggy bank.
Product – we need to prepare for rapid adaptation in the product (design, logistics and implementation)

We all know these things – now it is time to execute them ‘cause 2009 will be challenging, so let’s get ready for it.

Tal

So, how are we doing in this credit/tech crunch?

 I will not ask the silly question who has not been hit by this down turn - I assume that most hi-tech organization these days are feeling the pressure. What will 2009 hold for us is hard to tell but obviously we need to make a few changes in the way we conduct our businesses – funding is going to be hard to get and customers will cut back on their spending for sure – the perfect recipe for a headache.

I would like to focus this discussion on the way (I think) sales organizations should reinvent themselves due to this new market situation and my next post would examine what support they (Sales) will need from their product colleagues to be successful.

I think that more and more sales organizations are going to adapt a “laser approach” rather than a “shotgun approach” – meaning extreme focus on markets or specific customers which a sale can be achieved with higher probability rather than expanding over too many territories and opportunities.
This means:
•    Less territories to focus on
•    Increased efficiency in managing territories
•    Reduce operational costs

The first 2 bullets are linked together, which means we need to identify the markets carefully and have our sales people more in the territory to meet customers than flying around between territories (more air miles for the sales person but less over all effectiveness in selling). More than that, territories which seemed previously unappealing may now be the most appropriate ones to address – everyone wants to sell in Western Europe but maybe now the opportunities are in Africa – can this shift in approach help hedge the downturn? Who said that these days a sale to MTN (in South Africa) is less appealing than to T-Mobile (in the UK or Germany)?

Reduction of (sales) operational costs is a favourite one for CFOs. I think that more organizations will tackle this goal by relying on larger networks of agents and representatives which will deliver local sales at overall reduced costs. The sales people may be tilted more towards channel management rather than direct sales. What do we save – mainly travel costs which have a devastating effect on profitability. What is needed – versatile sales people and open minded sales management.

Tal

Special Meeting in The ALM Group - Guest Lecturer from Microsoft India Shay Mandel

Shay will talk to the group about: Microsoft Lab Management for smoother ALM process Abstract:

Meeting will take place this Wednesday, the 24th in Microsoft's offices in Ra'anana, at 17:30

Abstract:  

So much was said about using Virtualization in production and Data Centers, but Virtualization is even more amazing when it is used in the development lifecycle. In this session you will learn how to leverage virtualization and the new tools that are available in VSTS 2010 to speed up the development process, enhance collaboration and improve software quality. You will see how you can easily save a lot of time by using the new Lab Management tool to use virtual machines for easily deploying isolated environments for each developer and tester. Deploy the application automatically. Run tests and file actionable bugs that enable easy debugging, even weeks after the bug was filed, as if they occurred just now. Automate the build process and the continuous integration

For full description of the meeting visit Maor's blog

Registration link

Once upon a time we had a waterfall management system and requirements handling was so straightforward…

Not very long ago, defining the scope for software requirements management activities was quite simple:

  1. Spend a lot of time thinking and documenting in the beginning of the project (assuming that the result of all this mental effort will be a very solid definition that will not change)
  2. Send the documents/diagrams to the involved parties
  3. If they don’t supply you with a feedback, assume that they accept it, if they do have comments, make the minimal needed alterations
  4. Send the final version
  5. You are done! Wait for your new project


Today, it is very clear that the workflow described here is practically a recipe for disaster and those organizations that still implement waterfall methodologies in their development processes are very likely to end up like this


Orchestrating a successful product is extremely challenging and is an on-going effort that requires the coordination of multi discipline resources (in other words, what we call: Product Readiness), in this post (and the following ones) I will discuss the role of the product manager/ analyst/business owner in an rapid changing, highly demanding environment where every requirement is only final until the market has stated otherwise and that, on the other hand, performing changes outside of the original scope place a significant hazard on the ability to keep budget limits

Where is the product Manager when we need him?

In my last visit to one of our customers I measured the physical distance between the R&D department and the sales department – it was 15 strides so let’s say 14 meters. In the same day we had a project planning session after we sold a new project to a tier 1 international customer. After this meeting the same distance (14 Meters) seemed to grow to an unimaginative length.
The reason was that in this project, a critical software component of the system, was of grade and scalability anticipated for a  SME (Small Medium Enterprise) installation and not acceptable for a $4Billion corporate.

I was told by the product team – “…It works in other places just fine so why shouldn’t it work here…”

Gals and Guys listen up and pay attention to this delicate nuance, our companies are all about creating cash and value for the investors and shareholders and NOT about creating cool software… sad but true.
Too many times we see the product people creating a product and features which they like but are: a) totally useless and/or b) adhering to no acceptable standards by our end customers. This skews our sales efforts and deems them ineffective most of the time.
At best when we sell products which are rich in “redundant” features we take upon our organization a huge engineering and commercial challenge to build (quickly) functionality that will “secure the deal”. I am not a great programmer (hence my sales job) but even I know what happens when you develop and deploy new software at a rush and under extreme time pressure.

So please let me introduce the product manager. Yes, that quasi-sales and product creature which is responsible to gather customer and market requirements and get them implemented into -  the engineering plans, product roadmap and development project plans.
Gals and Guys, if you do not have a product manager involved in your daily product development routine then get them involved.. quickly! Their job is not only to fly to conferences and to sit in industry standards groups (boring!). These folks are here to ensure that what you develop really hits the spot with our customers and that the probes we send into the customers organizations make their way into your product development plans. Listen to them and make them part of your daily life just like that coffee break ritual you are used to in the office.

The art of integrating Product management into the organization is something that we all need to master.  Product management is the resource that will navigate the development towards the promised land – the land marked by our customers expectations and not by the developer’s craving for a new and cool java functionality in the product. This approach is not as cool but much more profitable for the business in the long run.

Are you utilizing product management to the max or are you just tagging them along to sales meetings so they can get out of your hair?

Tal

Product Readiness - an Integral Part of Marteting Strategy

Innovation Model


A client of mine has made a strategic decision to leverage on their strong base of hardware sales and move upwards the value chain into software and services. This is a bold and interesting move if we take into account the current economical downturn and the high level of competition in the market.

Ensuring a correct solution portfolio to start with is critical as this will determine the resources and set-up required.

One of the initial stages is how do we evaluate the products to fit into a model which will bring the highest value to the customers and yield the greatest return to my client.

The model above is one and by all means not the only one to evaluate the dynamics we are trying to quantify. The above model takes into account a multi dimensional evaluation of the top 10% of customers and strategic suspects and builds into it the competitive landscape we need to address. It also brings into the picture the critical needs and potential solutions required to meet the customer’s challenges.

A key factor and also one of the quickest ways to differentiate between vendors and service providers are technical and commercial innovation. The reason for innovation as a differentiator factor is that there are many cool and new technologies around, but mostly “me too” and therefore not unique. Technical and commercial innovation provides the measurable factor for a customer to choose one product over another. Commercial innovation is measured by flexibility of things such as discounts, payment terms and bundles.

Technical innovation is not only having a cool code it is delivering a complete package.  We need to ask ourselves questions such as - Can you provide assurances of a stable development environment? Can you demonstrate transparency throughout your process? What is the level and openness for integration? Is it possible to truly evaluate your roadmap availability? Do you have the support mechanism to service a growing number and demands from clients?

At Triple Jump we called this evaluation process Product Readiness. Product Readiness takes into account the customer needs, competitor’s analysis and functional features to ensure fit for purpose status. But more importantly we examine the readiness of the development environment, lifecycles of the product and ability to deliver a complete service.

With this client we have ensured that the identification and evaluation process are homogenous and aligned to the overall strategy. We have identified over five potential vendors that support our initial vision and are now evaluating there commercial and technical propositions via the model above and Product Readiness.

I will keep you up to date as to our progress and findings in the next couple of postings.

Why ALM and PLM are important to Sales and Marketing

In a former life my CEO asked me to reduce my marketing budget by 25%. I had a long think and decided that letting people go is too easy, there has to be another way.

A marketing organisation must not only provide service for the organisation, it has to mirror it. It was therefore, imperative to reshape marketing to shadow our business models and operations. The first thing we did was to align marketing to the sectors we serviced but more crucially to assimilate into the services organisations into the factory – Business consulting, System Integration and Managed Services.
Each of the above had sets of technologies, vendors, bespoke developments, commercial models…… all cost money and all were prioritised as important.

What we did is streamed lined as a joint exercise the offering per service line and joint up offering so we can all share costs. We also prioritised with the business what we focus on into tiers of importance. To manage this process we had Industry sectors plans signed and approved by the business and service organisations. This was a live plan that was owned by marketing.

So you might ask where does ALM and PLM come into it – well, one of the key indicators that we are inline with offerings and solution so we can make the marketing investment to drive it into the market was using ALM and PLM tools and processes so we can keep hold on things.

We had three key outcomes:
1. We were more agile in delivering thought leadership to the market.
2. We reduced more then the 25% of our budget but more importantly increased the visibility on the ROI marketing delivers.
3. We had a more client orientated services organisation

Bottom line – if you work in technology use the platforms available to communicate in the same language.
 

ALM User Group - December Meeting

The December meeting of the Israeli ALM user group in Microsoft will deal with the facsanating subject of Agile Development and the steps that a software organization should implement to achive the transition.

 The group meets on the second Monday of each month (on December, second Monday is the 8th) in the Dekel hall in Microsoft offices in Ra'anana. Meetings start on 17:30.

The user group page: http://www.microsoft.com/israel/communities/usergroups/. unfortunetly you can't register to the events from the group page, please use http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032396580&Culture=he-IL

 Meeting's Agenda:

The Agile transition:  Pragmatics steps required for a successful transition to Agile methods

Agile developments and scrum are no longer new buzzwords in the industry; almost everybody must have heard about it or even attended a lecture or two. In this meeting of the ALM user group we would like to move forward and discuss the pragmatic steps required for turning the agile concepts into pragmatic activities. We will discuss the implications on the people in your team, your working methods and of course your tools, and  how team system can support you in the transition.

17:30 – 18:00 assembly

18:00- 19:00

 The Agile transition framework:  How to build a successful Agile transition process  (Eyal Katz – founder of DevManage).
In this session we will discuss the challenges and suggest solutions for a successful agile transition. The process is based on adjusting the framework to the specific needs for the people, methods and technology of your organization
.

19:00 – 19:15 break

19:15 – 20:00

Agile case study – my transition experience as a Scrum Master - Gal Possek, Program Manager and Scrum Master, Amdocs

 

 

Dev Academy - The Team System Panel

Microsoft Israel is holding the Developer Academy event for the 3rd time on December 15th. The target audience are developers and technology professionals and will include a variety of lectures and panels. I will participate in the Team System panel and would like all of you that have an interest in Team System or ALM to attend.

Panel description: 

PNL03 - Align the development process with the Business using Visual Studio Team System
The current situation forces us to cut unnecessary expenses and align our development process with the business. In this panel we shall discuss the following issues in order to help you better focus your efforts: Team system deployment – Do it your self, Agile vs. Scrum and CMMI best practice for selecting process template, Glimpse from VS2010 and new power tools and Team system for non .net development teams

The chasm between product delivery and sales

Many years ago there was a legend from a big well known technology provider called Digital (old boys should remember, young guys, well, check Wikipedia). The legend said that on sales “missions” the engineers would never have a glimps of the customer before the deal was done. This enabled the sales rep to sell his dreams, collect the order and… run away hoping never to see the customer again in the office or for that matter in a dark ally as well. When the deal was done and the project was started the engineers walked in, looked at the product that was sold, then looked at their own “creation” and felt sick to their stomachs. “Where is that ******* sales guy” they muttered – nowhere in sight.  Those days are long gone.

These days when we sales guys walk into our customer meetings, we are armed with an endless array of sales documentation detailing features and specs, demos, brochures and nearly every dreamed, paper worthy, description of the product we are selling. Obviously the selling leeway is much narrower thus creating a huge “trust” between sales teams and their product/R&D colleagues. The trust is in the real understanding “the product really does what it says on the cover”. Well experience shows that, over selling by sales reps is usually (not always) coupled with under delivery by the product teams, so we are selling today the n+4 version of the product which will be available in 18-24 months time… this is a recipe for disaster.

One of the biggest holes in knowledge amongst sales staff is what really is there under the hood of the product and how to sell its current benefits. Too many times we are lectured by R&D about features 16, 17 & 18 whilst only the product people really know that they have barely got past feature 9… and that a deliverable product at any stage is only available 6 month from now…
Let me share with you some real life examples, which I am sure are not unique:

The company’s executives are pushing the sales team to deliver POs (purchase orders) at short notices. “We have a great product, just what our target customer needs and we are 9 months ahead of our competition” say the headlines. So the sales crusaders set off to the sunset to sell, armed with the “knowledge” that all is in place.
So a few months of work and here we come back with an agreement with a large multi-national customer operating in multiple countries – big opportunity, the one we were all expecting. Easy, we say, all we need to do is to give a product to each country for testing and a few weeks later, come back in to sign up the customer… We (Sales) are counting our sales bonuses and the management is leaking info to the investors – “the big one is being reeled in”. What happens next is the tragedy of misalignment between sales and product people… “the Product is late”, they say and we should wait “just a few more weeks”. Anger builds but we are seasoned professionals, we can set expectations with the customers and get over this unforeseen delay. Then come more delays, and yet more. The end is quite obvious; from a great opportunity, a commercial disaster is born. The characteristics of the disaster are many but could be summed up simply through lack of transparency and coordination between sales, marketing and engineering which causes chasms in product and sales understandings. The same chasms that were illustrated for Digital at the beginning of this entry.

In the next few entries we will examine how such chasms should be bridged in order to create an effective selling organization which not surprisingly starts not in the sales team but rather in the R&D, engineering and product side of the house.

Stay posted, more to come.

Tal

On the road to sales and product alignment
I once worked in an oil and gas project where the IT component was less than 5% of the total cost. One of the senior managers from the oil company told me he wants to have a bet with me that the IT element will be late and cost more by at least 10%. His argument was that we in the IT business have all the best methodologies (usually copied from other industries) but we rarely deploy or stick to our own preaching.

It is quite common to hear arguments between sales people and product development (product people) regarding the true status of product availability. Sales people will always sell what they can and easy and promise the heavens. Product people will try to bring them back to reality or join in the enthusiasm and agree to deliver features and elements that do not exist. We all know the end result of such discussions – the client has delays and usually has to pay more.

All of this can be fixed in a very short time but it requires the human factor to be better managed. I am not a tech head! I am a marketer but, Application Life Cycle Management (ALM) and Product Life Cycle Management (PLM) are a set of methodologies, processes and tools that I promote as they help me to bring more value to the vendor and to the customer. Alignment and discipline are keys to a cost effective and measurable value all around.

Think about it this way - When a sales organisation works in partnership, enabled by transparency and common goals with the product group it has a better chance in selling a product. The customer has detailed understanding of the delivery and the true costs required. The holy grail of up-selling and cross selling becomes simplified as the trust between buyer and supplier exists. The value of customers is not only in their expenditure with you but also in how they promote you and add to your brand.

If this short description and scenario sounds familiar then next time I will be expanding on some of the first things to implement on the road to sales and product group alignment.

By the way, the manager from the oil company was right!

Real value of Application Lifecycle Management
There are so many definitions for application lifecycle management out there; almost all of them discussing the relations between the phases of software manufacturing. There were times that I completely agreed with them, and don't get me wrong,on the methodological level: I still do, but on the practical level I think they left out the most important part: lifecycle management is all about cutting costs and effectively using resources to optimize your product value. IIn my opinion, the key success criteria for lifecycle process implementation are whether the business is able, at one glace, to find out the complete expected expenditure on a new feature and the timeline for its release. Software development should not be looked at through a foggy glass; all the information should be available and crystal clear for the decision makers. Once we are technically able to measure every new requirement coming from a customer or a feature suggestion by our product manager by its real value: the amount we are about to spend building it opposed to the expected volume of sales and revenues, only then we gain the ability of achieving well balanced technical/business decisions and focus all our efforts on the features necessary for our product success.
On Vacation

I was planning to dedicate this post to the fundamentals of Product Readiness, but it will have to wait since I'm going on a vacation (which is really being loyal to my paradigm, and adjusting my plans to current events J )

Will be back in a couple of weeks, all rested and ready to blog.

 

Product Readiness

When you look at the actual practices applied during a Product Readiness process you are very likely to find out that none of them are new to you (assuming that you are part of the software manufacturing industry). The main reason is that Product Readiness is a discipline that utilizes other disciples, breaks some of the traditional flows and connections and creates new process and values using the same known building blocks. Product Readiness is actually not very different from PLM (Product Lifecycle Management) or ALM (Application Lifecycle Management) in the sense that it contains phases like: product initiation and market introduction, growth, maturity and decline and aspects like: requirements management, design, development, testing, configuration management, build, release and deploy, implementation and support. Sounds simple? Well, statistics show that most software organizations (large or small, young or well established) are failing to successfully accomplish the traditional plans and expectations. Product Readiness is not about inventing new practices, rather, it looks at the challenges, difficulties and conflicts that are part of the organization culture and environment and builds a realistic process, that dynamically grows and changes in alignment to the organization's available resources. Since Product Readiness is about balancing between conflicting interests it is able to bridge the built-in gaps between software development, product and project management, marketing and sales and connecting between software architecture and technology innovation to business ambitions and the commercial environment.

In the next posts I will discuss these issues in more details and describe the levels of the Product Readiness model and the way they are applied.

More Posts Next page »