Archives

Is Your Product Strategy “Digital” Enough? (Part 2)

Part 2: Making a strategy more “digital”

Part 1 presented symptoms that arise in the process of implementing product strategies that aren’t “digital” enough—meaning that they don’t effectively anticipate or address the emerging needs of product managers and teams. If any of these symptoms are familiar to you and your team, it’s worth discussing how the product strategy might be strengthened to alleviate them.

Did We Go Wrong, or Just Not Far Enough?

A product strategy may have issues simply because it is unintentionally biased by the focus and experience of those who are tasked with formulating it. A CDO may bring a very high degree of “digital” influence to the strategy, but may lack pragmatic experience building and delivering a variety of products types at scale. Whereas a CPO may produce a very thorough focus on the “What” and “Why” but insufficiently factor the impact of changes in the “How” that will affect the performance of the product organization as they implement the strategy.

A strategy is often made less effective simply because its approach has been too cookie-cutter. Strategy, in a business context, is a tool for planning, consensus-building, and direction-setting among the executive management. The classic approach to strategy is that stakeholders (often with consultants) articulate a plan for the future — based largely on quantifying the known in order to project the expected — and then make decisions about the future. This strategy is given to the next tier of management to define the details, align budgets, and plan for resources and operational details. After the planning and budgeting cycle is done, the plan gets executed, with the outcome not fully measurable until completion.

Another characteristic of strategies is the urgency surrounding them, often expressed as a reticence to get feedback or analyze decisions and assumptions— we already have buy-in, just get going. This can reflect the challenge of building consensus and getting buy-in, especially where there’s a high degree of uncertainty or disagreement about the future. It may also be a tacit signal that there is a gut-level awareness that the strategy is incomplete or is glossing over some potential show-stopping issues, but it’s politically or culturally unacceptable to dissent.

Just because a product strategy has been produced and agreed to doesn’t mean it is correct or will be effective. And just because a product strategy isn’t all it should be doesn’t mean it can’t be improved.

Killing Zombies: Bringing a Product Strategy to Life

Static strategies can make a product organization or even a business look like a zombie — making mistake after mistake, completely unaware, and oblivious to anything except what the strategy dictates.

Strategies can become static if they are only used as an initial stage gate, if they provide little to no ongoing value, or if they lose relevance as time goes by because too many things have changed. Strategies are inherently static if they don’t acknowledge, allow for, and facilitate the adoption of changes — especially at levels that are clearly changing or where there is a high degree of uncertainty. Strategies need to be at least as dynamic and evolving as the context to which they are applied.

The goal is to be sure that the strategy doesn’t get stuck in the initial gate, but instead becomes a tool that remains useful. If there is a growing gap between what your product strategy said and what is actually happening, people should be asking: Was the product strategy missing some key points? Are we still actually following a strategic path or are we just bushwhacking?

A static approach can be made more dynamic—brought to life— in 3 ways (and ideally all three would be integrated as part of an ongoing product strategy function):

A systematic effort to identify, understand, and then categorize issues, risks, and areas of uncertainty
The point here isn’t to overload the strategy with details, or hope to address everyone’s concerns. Since every strategy has to be operationalized and tactically implemented, understanding the categories (and size) of issues, risks, and uncertainties along that path, in advance, gives a better picture of which things are likely to have a broader effect and should be explicitly addressed in the product strategy. This doesn’t mean there will always be a clear answer/decision. However it allows everyone affected to be aware of the issues, options, and current thinking behind how to address them.
A systematic effort to identify how success/failure of product(s) could influence overall success of the product strategy (i.e., develop a portfolio approach)
By understanding the business value of platform capabilities and products, and potential risks to delivery and market adoption (and impact on expected ROI), potential pivot points and shifts in priority can be identified as options earlier in the planning cycle and better managed. A portfolio approach starts with the idea that not all products are equal because:
- How you measure value varies across capabilities, products, or features. Some may be of low-value for near-term revenue, but instrumental for building competitive advantage. Some products may require market-building in order to scale or only be viable as part of a broader solution
- Different approaches to product development have different requirements. De-risking through an MVP approach assumes a product that will evolve through a feedback cycle, revealing dynamics that can’t be predicted today.

The idea behind a portfolio approach is that is that there is no sure bet on future outcomes. Knowing what you will measure and how you will interpret findings in advance means you are more likely to actually do it and be able to make smart decisions.

De-risking by looking for the important “unknown knowns” before planning and budgeting initial implementation programs
There is often useful information available that gets ignored because it doesn’t seem relevant enough to the situation at hand. Sometimes this bias occurs without anyone really being aware of it, because it’s built into the approach to strategy development.

For instance, a common tool used in growth planning is a framework called the Ansoff matrix. It’s a 2 x 2 with the horizontal axis representing existing and future products, and the vertical axis representing existing and future markets.

Right out of the gate, the focus shifts away from the other quadrants. They haven’t become suddenly less relevant, yet what they might imply is often assumed as not relevant to forward-looking product strategy. However, those in charge of product strategy can pull a clever trick: they can simply decide to make those other quadrants relevant by looking at them as inputs and exploring relationship scenarios between quadrants over time as a product strategy would be put in play. This will lead to questions that the strategy should seek to confirm as relevant/irrelevant, and when relevant, explain why, and based on what decisions and implications.

The goal is two-fold: (1) make sure there aren’t unstated assumptions being made by other areas of the business about what the product strategy is unaware, and (2) make sure project strategy doesn’t inadvertently miss key interdependencies. The following questions are examples taking this kind of approach when using the Ansoff matrix:

- What changes in how we currently do business will be needed when we are delivering future products for existing and future customers and to what degree do our product bets assume this will occur?
- What’s the risk to the product strategy if these changes (in how we do business) don’t happen as planned, or in lock-step with the product strategy implementation?
- Can we de-risk this in how we define, plan, and launch products, and if so, where and how?
- Are we expecting existing customers to eventually migrate to new products? If so why, and can they continue to use existing products as they adopt new ones? What does this imply for our product strategy in terms of product adoption requirements/legacy support requirements?
- Will existing products be relevant to new customers?
- How much do we know about additional needs of our current customers?
- How much do we know about needs of our future customers?
- What changes in requirements for new products and requirements of new customers would likely make our current approach to product management, (definition, development, and deployment) inefficient or unsuccessful?

Conclusion

There may be some reluctance to re-approaching a product strategy that has already been approved or is well underway. Every business needs to consider the kinds of issues they are facing and weigh the costs and benefits of a bespoke solution (i.e., fix it in a product-by-product context) or holistic solution (i.e., address it at a product strategy level). In either case, at least understand what issues can be addressed earlier and how you can improve subsequent strategy exercises. Taking a more considered approach to measuring the effectiveness of the strategy as it is implemented can also begin to shift the overall mind-set away from static strategies, and enable more flexible strategies that provide more value to the teams who implement them.

Is Your Product Strategy “Digital” Enough? (Part 1)

Symptoms

There is no single “right” approach to developing a product strategy. What makes an effective product strategy varies by industry, business model, stage of business, etc. It’s also a given that a business’s digital strategies will likely need to address areas beyond product strategy.

Many business leaders could confidently answer “yes” to the question posed in the title and justify it by listing out the products and services they think qualify as digital. All this really tells us is that they have digital products as part of their offering. It doesn’t tell us if and how digital has influenced their approach to a product strategy.

The challenge is that “digital” implicitly means that there will be things that need to be accounted for in a product strategy, things that weren’t necessarily considered relevant before. Digital, as a concept applied to business, means that value creation and customer engagement increasingly relies on software and/or software-enabled hardware. Software, as a way to create value, also has different economics than analog value creation.

And like most things associated with technology today, change is constant. The way software is approached, what it can do, and the process and resources needed continue to evolve. A product strategy is sufficiently “digital” if it understands these points and makes clear the key assumptions being made on these new kinds of issues.

Some might push back, arguing that it’s not product strategy’s role to define tactics, and it’s better to iron out the planning and implementation. However, it probably won’t be better if this outlook enables a culture and a dynamic in which product managers are forced to address broader issues solely based on what makes sense for their own narrow context. It also probably won’t be as successful an approach if it increases the odds that you will need to implement fixes and address issues very late in the game, where the costs and risks are higher (or the budget is gone along with unmet milestone deadlines). If an issue is relevant or applies to all products, but it is not to be addressed in the product strategy, then where and when will it get addressed?

Often there is too big a gap between what is covered in the product strategy and what is required to enable quality and efficiency throughout the product life-cycle. The good news is that just because a strategy is lacking doesn’t mean there’s nothing to be done about it. To address the situation, business leaders and those tasked with developing and implementing the strategy need to be on the same page, as far as understanding what the symptoms of an incomplete product strategy are, and how and why to deal with them.

Symptoms that a Product Strategy is not "Digital" Enough

One of the qualities often associated with digital is speed. As a result, product organizations are often struggling to increase productivity, quality, and efficiency all at the same time, while inheriting strategic directions that might not be fully actionable. There will always be issues and fires to put out, but if the root causes are misunderstood, attempts to fix and accelerate forward may result in the increase of issues and the spreading of fires.

When symptoms resulting from a static strategy are not recognized as endemic to the strategy, they are seen or treated as if they are confined to a specific product context, and solving for that context will fully eradicate the problem. (Smart money bets that it won’t.)

Symptom #1: The product strategy doesn’t anticipate/address the relationship between products and platforms

Just as there are many ways to frame a product strategy, there are many ways to define “platform.” That said, a common approach to developing today’s digital products and services is to create a broad set of capabilities that can be combined/orchestrated as products or services that can (1) be taken to market, (2) be made available to partners/customers through APIs, and (3) be used by the business itself to increase productivity. This is the basic premise of many approaches to digital business, and it is a core plank of a platform business strategy.

When a platform-approach is not well articulated and accounted for in a product strategy, then the strategy is subject to interpretation and evaluation in terms of products and features. This can lead to confusion and mistakes in how capabilities of the platform and individual products and features get prioritized.

Simply put, if a product or feature relies on a capability, then not having that capability means you can’t deliver the product or feature until you do have it. The prioritization of capabilities directly influences the products and features they support. As a result, the approach to the platform affects all products supported by that platform. It’s not uncommon to find businesses making substantial investments in “platforming” their products, yet product managers and platform architects don’t consider their domains as having significant overlap or interdependence. As such, the business measures progress based solely on product progress.

This lack of common conceptual ground isn’t just inefficient for product managers and teams tasked with delivering products. It can also affect platform development in how microservice architectures are approached. If service decomposition is too tightly coupled to today’s products, it can compromise the future flexibility of the platform.

Misunderstanding the platform-product relationship can also affect the approach to data implied by the product strategy. Without any guidance otherwise, different products may take different approaches, often without a common data model. Data for operational needs may be approached as yet another silo. Products that serve global markets also need to comply with multiple variations of local regulations. With data being a key component to the value of a platform business strategy, not having data addressed or reflected in a product strategy can be a costly oversight. It’s also not a good sign if a separate data strategy exists and it is not reflected in the product strategy.

Symptom #2: The product strategy doesn’t anticipate/address the relationship between changes in products and changes in process

While a product strategy doesn’t need to define the process to be taken on a per product basis, it should reflect the range of processes that the product organization will need to support. And it should anticipate if new products will require new processes.

If there is logical alignment between product, requirements, and process, using the right process increases the odds of success. If new processes are to be used, the biggest risk is people being unaware of the implications to their tasks. If they are an input to the process, or if they don’t provide the right input, the process effectiveness gets compromised. If they are a consumer of the output and they don’t get what they expected, they may disregard the output and do it themselves — and then the process is considered to be a waste of time and resources.

There are many ways to approach product development (user centered design, design thinking, lean UX, MVP-based product evolution, agile, scrum, Kanban, automation, etc.). Product managers may opt for a process that deals with risk and uncertainty by not overinvesting in features or use cases that haven’t been validated as providing real value to real customers. The idea is to get something out early and validate assumptions and next steps based on feedback. What is often missing is how this round trip will be done — what data will be collected, how it will be collected, how it will be analyzed, how the outcome will be used to inform ongoing efforts, etc. In the case of platform-based products, it is simply inefficient for each product manager to develop their own approach to data.

As processes evolve, so do the tools, artifacts, and ways of working. Often this evolution is driven by the opportunity to provide benefits and efficiencies across product development efforts. Examples of this evolution include design systems, UI/UX pattern libraries, and approaches to templating and componentization. To be most effective, these tools and artifacts need to be developed and evolved with input and evaluation across functions and stages of development (versus simply rising from the detailed development of a single product). In fact, if a tool isn’t a component of the product strategy, it may never fully come about or serve all the products.

Localization of products often happens after the product has achieved a degree of completion or maturity. Localization may simply mean a version of the product where certain aspects of the UI are different in order to account for differences in language. Many products will require deeper degrees of localization based on the differences in cultures and cognitive approaches of users. In some cases business rules will require substantial changes (e.g., which features might be available, how a product is purchased, how it is supported, etc.). A product strategy should at least indicate which products will likely require localization and how deep this localization might be in certain markets that are key to the success of the strategy.

Symptom #3: The product strategy over-emphasizes innovation but doesn’t adequately define what is meant by the term

While a product strategy needs to be forward-looking, simply calling everything it covers or implies an “innovation” can create problems. This is especially true if business stakeholders have one model of what innovation should mean and the product organization is faced with real constraints that produce a very different model that is not aligned with stakeholder expectations.

The product strategy should provide the context for defining innovation and expectations around innovation. This allows those tasked with implementing the strategy to make the right choice of process and set expectations for outcomes without being blind-sided by stakeholders applying very different expectations when evaluating the outcome. The point is not to drive innovation out of the products or the product strategy, but to make it much more explicit by what is meant and create a common understanding of what innovation means.

If your goal is to deliver innovation through improvements to existing products for existing customers, but your approach is geared towards disruptive or ground-breaking innovation, it’s highly possible that the outcome might be a version of the product that doesn’t fully cover the existing needs of the customers. Or it might require changes on the customer’s end that they aren’t willing to make.

The product strategy doesn’t need to define the ideal fit between product innovation and market. Experienced product managers know these issues. But they are not always in the driver’s seat of the product strategy. A product strategy that clarifies innovation helps product managers better frame assumptions and requirements around product adoption that should be factored into product definitions and product development.

Symptom #4: The product strategy refers to design only in the context of a role, or a specific stage of product life-cycle development

Design is both a process and the output of the process. Simply put, a business that sees design as role and constrained to a particular stage, is really saying design is only about the output. This is an indicator of low design maturity. One of the risks here is the belief (or expectation) that design will increase the overall effectiveness of the product simply by “finishing” or massaging and filling in around decisions that they inherit. While it is certainly more efficient to have design function this way within a fast-paced product organization, it’s unrealistic to think that design can fix a bad or poorly informed decision.

Design maturity means acknowledging and understanding how the quality of design output is tied to how well design processes are integrated in other processes (e.g., strategy development, product definition, innovation). It also recognizes that there’s usually a benefit for businesses and customers in having products share common characteristics in terms of quality and character of the user experience (e.g., single sign-on across all products).

Design maturity also recognizes that different design problems often intersect, and that a designer in one area of focus may not have the tools and experience to be effective in another area of focus. A product design team may own the customer experience for the product, but it’s very rare that the same team can address the overall experience the customer has across all products and all stages of doing business with the company.

Conclusion

Every business has the unique challenge of defining what digital means to them, and what it means to the products they bring to market. One of the most important things a business should understand is this: as the business becomes more “digital,” the product strategy has to reflect that shift. It must provide more explicit direction or guidance on issues that will affect all products but can’t be fully solved as part of the development of any individual product.

Part 2 will look at some ways to improve a product strategy that is in play but wasn’t born “digital.”

Why do Hackers IP Spoof & How to Prevent It

IP Spoofing is used to gain unauthorized access to a network by impersonating a source with authorized access. IP spoofing is a cyber attacking technique. The hacker pretends to be someone else and conceals their identity to gain access to a network and hijack the browser. IP spoofing is also called IP address forgery or host file hijack. Learn how hackers can access your private information through IP Spoofing, and what steps you can take to prevent it.

Pages: 1 2

It’s Not About the Features

I bought a Tesla a little less than 2 months ago. My wife, who I think would admit to being a competitive person, responded by updating her preferred brand of Japanese sedan to their latest-and-greatest high-tech model this past weekend. While her car cost only a fraction of a Tesla, it was surprisingly close in features. And, while it is not electric, her car even has some features that my much more expensive car lacks.

Like the Tesla, her new car has adaptive cruise control, lane-keeping, low-speed follow, collision avoidance, and other advanced self-driving features. Both cars are quiet, comfortable, have great sound systems, leather-like seats, touchscreen interfaces, and lots of trunk space. Doing the Tesla one better, her car also adds a heads-up display and quite a few more cup holders than mine.

There are, however, some tip-offs that the design philosophies of the two cars are quite different.

Her car has many purpose-specific buttons: one to turn on the music, another to adjust the volume, a set for heating controls, and so on. There are also some specific-purpose mechanical gauges and displays. The Tesla has no mechanical displays and very few purpose-specific buttons; there’s basically a large touchscreen. Most controls—even to unlock the doors—are “soft,” just like on a tablet.

While her car does offer occasional over-the-air updates, the Tesla updates seem to be a regular event, and the changes can be significant—not just tweaks and map changes. For example, there was recently a major UI redesign that completely altered the “look and feel” of most of the major controls of the car—even such fundamental controls as air conditioning. Like with a major smartphone update, I liked some of the changes and not others. It was quite a bit different than the layout I’d just started getting used to.

This morning, I got another big surprise: Last night while I slept, Tesla added a “navigate on autopilot” feature to my car that adds significant additional self-driving capabilities. This new feature allows the car to not only “stay within the lanes” on the freeway, but also to enter and exit the freeway, change lanes, and change directions—all based on the final destination I give it. It still requires driver confirmation (at the moment) before it actually makes these direction changes, but the car is now able to take me where I want to go without my hands-on management, just my overall supervision. Also, not incidentally, this same update fixed the most significant things that I (and I suppose many other people) did not like about the recent UX update.

It’s like I got a new car—again.

As I was driving to work this morning—or, as I should probably say, being driven to work this morning—I thought about how this situation perfectly illustrates the power of a platform software architecture.

From a software standpoint, the Tesla was clearly conceived of as a platform that supports transportation. New software applications on that platform can be changed and deployed rapidly. My wife’s car, on the other hand, was thought of as a single-purpose system—specifically, a car—and not as a platform. In my wife’s new car, the button that turns the audio on and off will still turn the audio on and off years from now. Likewise, the mechanical speedometer will still be the speedometer. That’s all they do — and all they are ever going to do.

In contrast to a single-purpose system that focuses on delivery of specific one-off, “hard coded” features, a software platform prioritizes the ability to change and adapt. In other words, a platform’s primary purpose is to enable improvements. This emphasis on flexibility over perfection reflects a philosophy of “Kaizen,” or “continuous improvement.” In this approach, you aim to make something better than it was before, as opposed to trying to make it perfect. Ultimately, of course, we get closer and closer to perfection in this way.

The modern “Agile” paradigm for software development also has, at heart, the realization that “things will change.” This is inspired by a more negative spin than Kaizen, namely: even if it’s great today, it’ll be an antique soon. In both Kaizen and Agile, the strong recognition is that building for change is essential—both to support improvements and to avoid obsolescence. A platform approach is first and foremost a means to do this. A platform is what allows you to “embrace change” and make it work for you. A single-purpose system, by contrast, tends to be a “what you see is all you get” proposition.

While a platform approach does prepare you for change, it comes at a cost. A platform approach is almost always more expensive to develop than a single-purpose application. Platforms also generally cause you to deploy a less feature-rich system than you’d like—at least initially. Of course, as time goes on, your ability to rapidly deploy new features enables you to blow past a purpose-built system and deliver feature-richness and the ability to keep growing. On day one, though, you will likely have fewer features deployed in a platform approach than you would with a same-cost single-purpose system.

In many business situations, the ability to rapidly and cheaply add or change features delivers more business value than a difficult to change, feature-rich product. Companies with feature-rich but fragile code bases are common, and they are under threat by more nimble competitors who can move quickly. In human evolution, it was our adaptability as a species that led to our success. Likewise, the nimbler software platform and company is often the winner. While it is not always the case, the software that aggressively moves forward will often beat the one standing still.

My wife’s car was less expensive, in part, because it is single-purpose. Her car will have the same capabilities in a few years as it does today. And even if she and I were at near feature parity when she bought her new car last weekend, my Tesla has already pulled ahead in the feature comparison. She’s owned her car for less than a week.

Because I chose to buy into a platform, I can’t even imagine what its capabilities will be several years from now. I only know that it will be better tomorrow than it was today—and it will keep on going.

I guess I’m a bit competitive myself.

Enterprise Social Networking is NOT Social Networking

When I launched an enterprise social network (GLO) for GlobalLogic few years back, several of my friends and colleagues questioned me, asking the rationale of this initiative. There was a fear that such platforms would not only adversely affect the performance of employees by giving them a platform for microblogging, photo sharing, and activity streams, but it would also be daunting to HR policies and corporate governance by making the overall environment too open.

I myself was not sure whether it was the correct investment direction, or whether I should first only focus in making the company's back end ERP systems more reliable and integrated. This alone is a challenge and number one priority of enterprises like GlobalLogic, which is growing every year, continuously adding new geographies, absorbing new business models, optimizing services portfolio, and re-structuring the organization.

GLO-1

Five years later, the picture is clearer:

With over 300 online communities on GLO, 70% of our global workforce uses the platform for sharing their updates, writing blogs & papers, connecting with colleagues, posting pictures, submitting ideas, asking questions, and performing several other activities on everyday basis. The platform has turned into an organic knowledge repository of the company, having so much useful information

GLO has become the primary platform for company executives to collaborate with the global workforce and participate in bidirectional discussions — therefore helping better manage the above-mentioned moving pieces. For example, our CXOs now use their dedicated communities on GLO for posting key updates and communications because all employees are automatically subscribed to these communities.

The quality of our HRMS enterprise data has improved by 90%, with people being able to look at information that was earlier locked in back end ERP systems

Some of the core business processes are front ended via the GLO platform. Because they have a social fabric around, they are more effective and efficient. Examples include employee self-service, competencies management, new employee joining process, employee referral board, goal management, performance management, and several engineering project management tools.

GLO is a primary tool for the Resourcing function across all geographies because it allows users to identify "who knows what." This feature lowers the cost of vacancies closure via internal fulfillment by more than 20%

GLO-2

So the question is, "Was the fear that existed three years back in everyone’s mind unfounded?" Absolutely not. Lots of social networking platforms die because people find no enterprise value in them. To make these platforms successful, you must have (1) the right organizational culture and (2) the right integration with core enterprise back end systems.

The first question you should ask before spending a single dollar on a social networking platform is, "Is your executive leadership bold enough to ride the wave of an open, social collaboration environment?" If the answer to this question is yes, then the next question to answer is, "Who will be the actors on this system? Is it just humans, or humans along with backend enterprise systems?" If answer to this question is just humans, then pause for a moment, because it probably will not lead to where you want to be. That’s where I assert that enterprise social networking is not social networking.

Enterprise social networking means a meaningful integration of people, processes, and back end systems. If your people only generate activity streams in such a system, it is not an enterprise social network. Enterprise social networking is all about contextualizing the data sourced from the back end enterprise systems and presenting it in a format that attracts employees' attention and then interests.

The below figure represents this thought and takes it farther by making a recommendation to build the capabilities of the enterprise social platform so that the "social app" can be developed and deployed in a crowdsourced model. It presents a unique win-win situation for the enterprises and their people, whereby people are using the contextual information emitted by the enterprise social platform and using that information to further enhance the platform by building and deploying social apps. This has a huge potential to lead the innovation in enterprises.

By using the right mix of organization culture and technology integrations, enterprises can derive huge value by keeping their people motivated and turn them into a truly global innovative workforce, which is a top challenge of every multinational company.

Predictive Hiring (Or How to Make an Offer Twice as Fast)

In this article, I would like to describe how GlobalLogic is changing the approach to contracting with new technical specialists. We want this process to be effective - not only for our customers, but also for engineers.

Before explaining the changes, I am going to outline the most common way of involving new technical specialists in IT service companies. I will also explain the downsides of the usual approach for both companies and engineers.

Traditional Approach

Recruiters look for specialists within the company or on the market. Matching candidates are invited to HR interviews and then to a technical interview. If these go well, the candidate is usually interviewed by a project manager and then must pass one or more interviews with a potential client (depending on the specific project and agreements with the client). If the candidate is rejected at any stage and is then offered an opportunity to pursue another position, the entire process, except HR interviews, has to be held anew. Meanwhile, the candidate has no guarantee that he/she will be hired to a project.

Disadvantages for Engineers

Firstly, they need to pass many interviews. Although companies are trying to reduce the number of interviews for alternative projects (if the candidate was not qualified for the initial project), it is not always possible.

Secondly, apart from passing interviews, a candidate has to perform tasks on his/her current project. This is often inconvenient and drains energy and strength from candidates while also impeding preparation for the interview.

Additionally, feedback after each stage of the interview is often not given at once. The candidate has to wait days or even weeks without any guaranteet he/she will be picked for a project.

Due to the this, candidates often go to multiple interviews in order to increase their chances to quickly change a company or a project. Consequently, they accept the offer that comes fastest, even if the project is less interesting or promising. On the other hand, interesting projects usually have many stages of interviews.

Of course, the tendencies mentioned above do not necessarily take place. There are many cases in which candidates find interesting projects without facing many difficulties, but this often depends on luck.

Disadvantages for a Company

The first disadvantage for companies is, in fact, the same as for candidates — a large number of interviews that take a long time. A company not only organizes many meetings with the candidate, including communication with the customer, but also waits 2-4 weeks after a successful interview for the candidate to start working.

The second disadvantage the risk of losing a candidate because an offer from another company comes faster. This often happens when the customer takes a long time to choose an engineer for a project, even if the client loses several good candidates in the process.

The third disadvantage is that, even after several interviews, it is difficult to choose the best candidate. That's why project managers and customer representatives tend to take time and try alternative candidates. A perfect candidate that complies with all the requirements is rarely met;however, if a specialist is already working in the company and feedback is available, the decision about him/her is much easier to make.

Predictive Approach

As a company, we decided to change the approach when searching for candidates. Instead of using a principle "The project is primary, the company is secondary", we decided to go with the opposite approach: "Join the company, then join the project." If, based on the results of the first technical interview, we believe that a candidate is suitable for one or several of our projects, we immediately offer cooperation and sign a contract. That is, we are ready to pay him/her and take all the risks before a project manager and a specific customer interview the candidate.

There is no trick. It is the same contract he we provide to specialists whom we take directly to the project. We bear the same mutual obligations, and we continue to apply the traditional approach when needed. It is more important for useto secure a good specialist, even if we will subsequently need to spend time finding a suitable project. . There is no difference in the compensation package. The probationary period begins when the new expert joins the company and does not depend on the time when engagement in a project starts.

Over the years in business, we have developed a number of expertise areas, including Java, .NET, C/C++, Embedded, DevOps, Mobile, UX/UI design, QA, and JS. We choose specialists both in terms of 100% compliance with a certain project and in terms of compliance with the technological areas we develop.

If we like a candidate as a technical specialist, we will always be able to find and offer him/her a suitable project and a good customer. We have the opportunity and resources to sign a contract with the candidate and fulfill our financial obligations before going through all interviews. At the same time, we continue looking for a project while the candidate is in the interview process.

Experience shows that, on average, it takes 26 days from the date of a company signing a customer contract to match a candidate to that project. Although this is faster than waiting for a specialist to exit the market, we often find a suitable project within about a week. Using the predictive approach, we have attracted around 200 engineers to the company since last April. More than 100 of them are in Kyiv, and 70% have already chosen projects they want to join.

Many candidates ask, “Is there a maximum period of staying in the company without an allocation to a project?” I want to emphasize once again that we treat engineers found predictively in the same way as other engineers. In each case, the decision is made individually. However, since changing companies can be stressful and candidates expect stability in a new position, we guarantee that a specialist may stay in the company for a minimum of 6 months. This is not the maximum period and, as I said before, the decision in each case is taken individually.

Advantages for a Candidate

Advantages in the proactive approach are opposite to the previously discussed disadvantages of the classical approach:

A candidate receives an offer immediately after a successful technical interview. On average, this takes no more than 3-4 days.
When a specialist joins the company, he/she can choose a project and prepare for the next interviews in a calm atmosphere, when there are no tasks within a current project and no pressure from the fact that he/she needs to change companies urgently.
During the adaptation period, a specialist can learn more about the company and learn internal processes before he/she is assigned project tasks.
While the project is under consideration, there are opportunities to focus on self-development, improve knowledge and participate in the company's internal research projects (so-called Proofs-of-Concept [PoC]). We do not want our newcomers to sit around; on the contrary, we always welcome knowledge development and participation in activities that are beneficial to the company and the engineers themselves. Moreover, we have a very strong training base available to all specialists.
Finally, engineers have an opportunity to choose a project from the proposed options and refuse uninteresting ones. While we expect that the specialists we take predictably will not look for a unicorn project (the ideal and mythical one where everything is always is good and never bad), we also understand an opportunity to refuse unsuitable offers should exist. Both HR and management would perceive it normally.

Advantages for a Company

We find the right specialists faster. If we are sure that the candidate is suitable for us, we do not need to wait for the customer’s confirmation.
This situation is beneficial for projects. Project managers and clients are often more willing to take candidates who have already spent at least a few weeks in the company, as a manager can better see if an engineer fits a project than if they'd only interviewed.
After a successful interview with a client, a specialist almost immediately starts working on the project. There is no need to wait for 2-4 weeks for a candidate tobe transferred from another company.
In addition to solving tactical staffing tasks for specific projects, we also solve a systemic strategic task. Due to this approach, searching for and attraction of specialists becomes more effective, because we avoid pressing deadlines and reduce concern from customers.

Usually, we quickly find a project for a specialist. Candidates are satisfied, which means they are loyal to the company and tend to cooperate with us longer.Even if the candidate was not picked for one, two or even more projects (in very rare cases), we keep him/her in the company, and more importantly, help him/her to gain new experience and skills.

Business Benefits

There is an increasing trust in us from clients who receive a specialist for the project immediately after the interview. This allows us to fulfill our obligations on time, even if the client needs a lot of specialists as soon as possible.

Ultimately, this allows us to grow our business faster. If customers are able to get more people to join the project quickly, they begin to consider the company in particular and Ukraine in general as a more attractive place for development of their products. I am certain an increasing number of service companies will use this approach to attract engineers. This is also good for engineers, because the more businesses come to the market, the more choices and offers they will get.

Possible Disadvantages

In this article, I have emphasized the advantages of the new approach,but I would like to add that - depending on the situation or wishes of a specialist - this approach may be less suitable than other methods. This can take place in the following cases:

The specialist wants to start a new project immediately after joining a new company without a single downtime day. Even with the traditional approach, this does not always happen, but the chances are higher than with the predictive one.
Only the project is important to a specialist and not the company (outstaffing approach when choosing a company for work). In this case, the candidate needs to understand what project he/she wants to work on and search until this project is found.

IoT Security Concepts

Let us first start by defining security in an Internet of Things (IoT) context, as it can be understood in very different ways, and the term is often used to describe only a single aspect of the question. We can categorize the different meanings of the word into three different groups: lifecycle security, communication security, device security.

Lifecycle security covers the ability to securely and remotely manage a device at the different stages of its life, from configuration, monitoring, and upgrade until its decommissioning or revocation. This is essential to guarantee that devices are actually used in an expected way, especially when managing large deployments.

Pages: 1 2 3 4 5 6 7

Platforms: A Business Model for Strategic Growth

Major Macroeconomic Shift from Products to Platforms

The greatest economic disruption since the Industrial Revolution is currently taking place due to profound value chain and asset value changes in modern business practices. Physical and digital worlds are merging, creating new forms of interaction between businesses and people.

The traditional organization lifecycle flow — from design and creation to selling and consuming specific products — is evolving in our digital world. While particular stages may be removed or merged, this overall transformation introduces a new instrument called a platform.

In this new platform business model, the main assets take the form of interactions between producers and consumers. Elaborate algorithms and data management solutions enable an evolved user experience, and an optimized costs structure enables rapid growth for businesses.

What is a Platform?

Platforms are open intermediary interfaces through which suppliers and customers meet; they are multi-facial structures forged by their users and suppliers. Both sides are engaged due to a number of benefits created by the platform ecosystem.

Users are attracted to platforms for many of the following reasons:

Platforms memberships are mostly free-of-charge for consumers.
Modern aggregators are easy to use and offer a very wide range of products and services.
Buyers can communicate with each other, creating peer-to-peer communities.
Prices are lower because of internal competition and reduced operating costs.
Platforms offer seamless logistics and customer care.

Suppliers are driven by the following factors to choose platforms:

Platforms attract many users, so they offer a large market.
This market can be easily accessed, and costs of using a platform are comparatively low.
Using a platform brand and UX enables suppliers to improve their digital image.
Because sellers can build relationships with buyers, platform integrations may replace or significantly enrich their own digital presence.

Platforms also empower entire markets through the following factors:

Network Effect: Two user sides create content and value for each other and for the platform.
Scalability: Freed from infrastructure problems, businesses can make a rapid jump in scale, as well as fast internationalization.
Asymmetric Growth: Platform ecosystems create complementary markets and may develop sideline opportunities.
Horizontal Communication and Collective Intelligence: Effortless interactions and analysis of collected data help businesses follow consumers’ expectations.

Players of Platform Ecosystem Adoption

Platform business development started with digital-born technology and retail companies (e.g., Amazon, Alphabet, eBay), and now they are dominating the digital economy. Non-technology industry leaders who have realized the power of digital ecosystems are actively developing their platform strategies. Depending on the type of company, there are different strategies in a platform economy:

Asset Light Businesses
Asset light businesses (i.e., don’t own physical assets) like Uber or Airbnb have created their entire business models around platforms. Such companies are pure platform players, and as industry disruptors they totally rely on the power of optimizing ecosystems. Although they primarily drive new platform models, some develop in the direction of middle/heavy asset businesses by investing in tangible assets. For instance, Uber is investing in a driverless fleet of cabs. The majority of modern startups belong to this asset light category (according CB Insights, 70% of unicorns are platform companies).

Mixed Businesses
Amazon and Apple are vivid examples of companies that combine their own goods or services with a platform. They both leverage ecosystems effects while controlling their own product supply chain.

Asset Heavy Businesses
Traditional corporations — especially industry leaders like General Motors or General Electric — have started using the strengths of platforms to build sideline businesses that primarily target the consumers of their core products. For example, in December 2017, GM introduced the first automotive commerce platform for on-demand goods and services reservation. Creating a new consortium model, asset heavy companies often start with bringing their partners/suppliers to a platform in order to drive standardization. Then they involve their customers and distribution channels to get to new verticals. Besides building their own platforms, another option for non-technology enterprises is integration with existing ecosystems.

Advantages and Risks of Platform Integration

To be successful in today’s competitive landscape, enterprises across multiple industries must integrate their mission-critical components with digital ecosystems. They usually take the first step to lower costs and spread risks. In this way, their main business functions are tightly connected to a network of digital partners.

On the one hand, in the near future all companies — regardless of their nature — will have to integrate with third-party platforms to match the standards of customer service, technology maintenance, and other processes of their digital competitors (especially related to client interaction). But on the other hand, relying on online platforms not only means giving up control of product and brand presentation, but it also hands over the gathering and management of increasingly important customer data to the platforms.

However, as digital platforms develop in size and market power, the risks of neglecting such opportunities will become higher than the drawback of not having complete control ovwe the value chain and data. Customers will turn to online platforms as the main point of search, driven by the platforms’ enhanced user experiences, customer care, and broad range of products.

This tendency is not limited to major consumer-facing industries like high-tech, retail, and media. Platforms are also disrupting connected healthcare, heavy industry, education, hospitality, insurance, payments. They are event impacting improbable sectors like politics through online selling platforms, communication systems, social networks, and AI intermediaries.

Therefore, defining a platform ecosystem strategy should be among the core components of corporate planning. From the implementation side (i.e., maximizing positive effects and minimizing risks), we recommend aligning your network strategy with the right choice of platform-enabling technologies, like modular software architecture, IoT, cloud technologies, big data solutions, and AI solutions (depending on whether the company wants to develop a new platform or integrate with existing platforms).

GlobalLogic unites under one roof the technologies needed for platform development, from embedded to cloud, and from to data analytics to UX. An advisory-based approach helps our clients choose the optimal platformization strategy and implement it in the most effective way.

12 Secrets of Digital Transformation: Part 12

Secret #12: Plan for Success

When you begin a transformation project, you will of course believe in its success. But let’s face it: that’s at an intellectual level. On an emotional level, truly disruptive change that transforms your company or your entire industry, and that enables entirely new ways of doing business -- nine times out of ten, that level of success just feels unreal. A long shot, a hail-Mary pass, a last-ditch effort—choose your metaphor. It’s not that you lack confidence—but rather that this degree of success is just hard to imagine.

However, as you do the hard work and execute your technical transformation strategy, at some point it will hit you viscerally: “I’ll be darned, this whole thing just might work.” This might be after a demo, some wins with an MVP, with early-access customers or focus groups or receiving some other concrete or somewhat unexpected support.

When that “gut check” point comes, it’s time to start actively planning for success—that is, to start thinking concretely about the actions you and your company should take when you have in fact transformed to a new type of company. You’ve already thought about it abstractly, of course, but now it’s time to get down to nuts-and-bolts. In particular, you need to decide when to go “all-in” and start cannibalizing existing work streams to feed the new initiative. In general, it’s good to hedge your bets as long as significant uncertainties remain. However, the point will come, soon, when you need to commit fully and as a company so that your transformation initiative will succeed.

Some signs of looming success include:

Growing alignment and excitement in your company, from line level to board level
Top people—even if they were previously skeptics or rivals—now want to come on-board, or even to claim credit for the work already done
Decrease in opposition. People are pro-actively removing obstacles for you, even before you ask them, rather than everything being a constant uphill battle.

Perversely, political struggles may actually increase as your success is seen as more likely. When the previously uninvolved or peripherally involved fully understand that a transformation will actually happen, many will start jockeying for position in the new order. Your task as a transformation leader is to keep things focused so the value of the transformation is not diluted. There’s the old saying that “There’s no limit to what you can accomplish if you don’t care who gets the credit.” But at the same time, you need to mitigate the risk that your transformation initiative will be hijacked into familiar alignments and “more of the same” thinking, and therefore lose a lot of its value.

Unless you have a truly Machiavellian turn of mind, it’s unlikely that at the outset of the transformation project you will be able to predict the political issues that will arise near the end. I’ve found that the alignments that occur are often surprising and unexpected; in particular, many (though not all) of the initial detractors may become strong and principled supporters. And, of course, the opposite can occur as well. My best advice is to stay alert for both opportunities and threats that arise from the success of your initiative, both personally and for the initiative itself. I also have come to believe that the best sign that people really “own” something is when they come to believe it was their own idea. But, of course, as the change agents, you and I both know better.

12 Secrets of Digital Transformation: Part 11

Secret #11: There is more time than you think to finish — but less time than you think to start

By definition, a crisis is a problem you can't solve with the time or resources you have. Or so you believe. Regarding your company’s technical situation, you may feel you are out of time; there is no hope. But there’s a saying about crisis that I like to keep in mind: “Don’t confuse the end of an illusion with the beginning of a crisis.”

Many times, when we begin a transformation project, we do so in response to a perceived crisis:

A competitor may announce a transformational or disruptive product
A 3^rd party company or technology may impinge or seem likely to impinge on your industry;
A startup develops something customers have previously been asking you for, and begins taking your market share away
Customer behavior has begun to shift radically and you can’t keep up with the changes.

These are indeed urgent and important situations, but in most cases the root of the problem was already there: it was unmasked by the external situation, not caused by it. In other words, you are witnessing the end of an illusion, not the beginning of a crisis.

My point in saying this, by the way, is not to persuade you that everything is OK, and certainly not to encourage you to stay where you are. If you’re in a transformation situation, you probably do have a real problem and you really do need to act. However, panic or a sense of impending doom is not going to help. The situation you are in was probably years or even decades in the making. If you are a sizable business, it will take you at best months to even begin to alleviate it, and probably one to two years or even longer to truly resolve. Some companies with deep technical debt can take three, four, five years or more to really “fix” their underlying issues, even though incremental releases may allow them to be partially mitigated faster.

I’ve been surprised several times in my career when I thought my company was way behind the competition, only to find that we were in fact first, or one of the first, to deliver. That’s because in many cases you are comparing your own internal reality to someone else’s hype. If your competitors are good at hype, but you are good or become good at delivering products, you can still win, even when it may look like you’re too late. Also, even if you are not first to market, it takes the public a while to accept a new product or business model. You’ll generally be seen as an early entrant even if you are second, third or even later, even if shipping takes months or quarters longer than you’d like.

If your company has strong market or domain presence, a loyal or otherwise “locked-in” customer base, or significant name recognition, you can beat earlier competitors who do not—and compete effectively with many others who do. I remember when I was at Rational and we were working on the Rose 1.0 software design tool—a new product category at that time. Several months before we were ready to ship, a number of tools with similar software architecture drawing capability started to come on the market. They didn’t have all of our capabilities by a long shot (no code generation, for example), but they did do architecture drawings. I talked to one of the product management team and he told me “Don’t worry about it. The best thing that could happen to us is to have a large number of weak competitors. They’ll just create market awareness for us, and we’ll win.” He was right—and we did.

A spectacular example is, of course, Apple. The world had pretty much written off Apple as a viable business by the late 1990’s, saying that it had lost its technology edge and was consigned to a long decline into total market irrelevance. This situation took a while to fix; in fact it took Steve Jobs and his team four years of hard work to turn Apple around technically (counting from the time Job’s re-joined as CEO in 1997 until the time the iPod and OS X shipped, both in 2001). In other words, even after the world had written Apple off as a viable company, they still had four years in which to mount a successful turnaround. And what a spectacular turnaround it was. Granted, even in decline Apple had a lot going for it in terms of brand and customer loyalty, and none of us are Steve Jobs. But the lesson we can take from this is that if our company also has non-technical assets such as consumer loyalty, domain expertise, brand recognition, revenue streams / tangible assets, or other types of assets, there is hope. We may in fact have time to implement our technical transformation, even if we are in a deep hole today.

While shipping later than you want to can sometimes be overcome, starting work too late often cannot. The dirty little truth about software development is that it generally takes longer to develop the product you want than you think it would. Even with great planning, great management, and great processes like Lean and Agile—practices which we follow and strongly endorse—there will always be some bottleneck that takes longer to resolve than you expect. This might be in an area totally unrelated to the software itself—project funding, requirements analysis, regulatory review, external or internal third-party dependencies, etc. Its predictable that something unexpected will happen, and that this will make things take longer than you think.

After fighting it for years, I’ve come to believe unexpected events are simply part of the nature of complex systems—that is, systems and programs with many “moving parts.” Your best strategy is to plan to adapt and respond, in addition to mitigation of known or reasonably foreseeable risks. You can and should work to remove every obstacle you can anticipate, and take advantage of all the efficiencies that modern software development has to offer. We are lucky to be in a time where many things that once were hard and time consuming—for example, setting up the physical hardware infrastructure—have now become much simpler (due to cloud and containerization technologies in this particular case). Many previously difficult and expensive vendor selection alternatives are now addressed by multiple free and widely used open source packages, or cheap open source-derived and cloud-hosted alternatives. But even with all these advantages, people still get sick or quit; natural disasters occur; management, customers and investors still create unexpected opportunities or hurdles to jump over; and, generally, stuff happens that you cannot control.

These are not excuses and all these contingencies can and should be planned for and aggressively worked around—however I can tell you with almost certainty that when you are in a transformation scenario, if you are thinking more than single-digit weeks / a couple of months out, shipping on time will be more of a struggle than you currently think it will. If you have a very near-term goal, you can indeed generally hit it provided your goal seems ridiculously easy at the outset of the work. But it will still be harder than you expect. If you are thinking many months or several quarters out, you will almost certainly be late or not as feature rich as your current plan calls for, due to the cumulative effect of now-unexpected events.

Things are different once you become a well-oiled machine. But even there, experienced companies and teams still plan for uncertainties and generally hedge their externally (customer) committed dates and targets, even in this modern era of Lean / Agile software development. They do this, generally, by prioritizing their objectives (rank ordering and setting “Must, Should, Could, Won’t” cutoffs on the backlog for the release), focusing on the most important items, and staying “Agile” to accommodate the surprises. Their professionalism comes from recognizing the reality of the unexpected, and being able to accommodate it without stress.

Once we have an idea about where we want to end up, choosing precisely where to start becomes another important decision. In large companies, I often recommend that clients choose a project that everyone has wanted to do for a long time but which has never been successfully implemented. Ideally this project should create significant upside for the company if successful—for example, opening up a currently untapped stream of revenue. On the other hand, it should have limited downside risk, in the sense that if the project fails, it won’t tank the company—or negatively impact revenues in a material way. The reason for these conservative criteria is not that you expect the project to fail, but rather that they allow people to feel that it’s safe to take a risk, change their behavior, and to do their best work. These criteria set people up to be heroes if successful, but is not so career- or revenue-critical that people need to fear making mistakes or trying new approaches. In other words: high upside, limited downside is situation where people can do their best, disruptive work.

For some companies, there is no “hedging” or “Plan B”: the company needs to transform or die. While small companies may literally go out of business unless they move fast enough, for a significantly sized company things are rarely that quick. Generally, the worst case for a large company is a long, lingering erosion of market share accompanied by top executive departures, layoffs, and ending in an ignominious acquisition of the remaining assets by a competitor or disrupter wanting to buy market share. That’s bad enough.

In “transform or die” cases, wholesale re-invention is indeed required. Generally, however, your best plan is limit the impact of new initiatives on your current revenue generation activities as much as you can, until you have demonstrated success. Move in parallel to the degree that you can—then go “all in”. Apple, again, is a good role model here: in turnaround mode, they continued shipping and doing active engineering work on their then soon-to-be-obsolete operating system (MacOS) while, in parallel, developing their new operating system (“OS X”) as well as disruptive new products like the iPod. They didn’t start cannibalizing their MacOS revenue stream until its successor, OS X, was well established.

Overall, your best mitigation for uncertainty is to start now, and to prioritize your work so you do the most important and risky things first. That way at any given point in time, you at least have the most important items completed. And if you do encounter a risk, you have maximum time to mitigate it. But this only works if you start. Thinking and planning is great and necessary, but it doesn’t turn into working software until you actually start work on the software!

URL copied!