Introducing Icenium – an Integrated Cloud Environment for Hybrid Mobile App Development

Today is a day that my team and I have been looking forward to for a long time. Today I am happy to announce that Icenium, an Integrated Cloud Environment (ICE) for hybrid mobile app development, is now available to everyone!

The Story Begins

Back in July 2011, I left Microsoft and joined Telerik to take on an ambitious idea. In my time at Microsoft I had spoken with hundreds of developers and was able to witness first-hand the frustration that many of them felt working with Integrated Development Environments (IDEs) – they were big, bloated and most were designed with only one platform, or one platform vendor in mind (e.g. Visual Studio, xCode, etc.). For developers that targeted multiple platforms, using these IDEs meant downloading, installing and managing multiple platform SDKs and two or more separate development environments. For example, targeting the most relevant platforms in the world today – iOS and Android – meant using xCode with Objective C and Eclipse with Java, along with all the SDKs and tools that go along with them. Nearly 3 GB of downloads to install and maintain (not to mention, you have to have a Mac OS X environment, automatically excluding Windows-based developers). I was no different from the developers I talked to. I used these tools all the time. They took up a lot of my time to download and configure, they took up a lot of hard drive space, and they required a powerful development machine.

I also observed that while I was writing code, I was also listening to music from Pandora, saving documents in DropBox, and keeping notes in Evernote. Nearly everything I used daily was not only cloud-connected, but the cloud played a significant role in enabling the technology; that is, the technology wouldn’t have functioned without the cloud. Everything except my development tools (OK, maybe I’d deploy an app to the cloud, but the cloud didn’t aid me in my development efforts).

An ICE Age is Coming

The idea that a development environment required all of the SDKs and platform dependencies to be installed locally on a development machine with massive RAM and a big hard drive felt so antiquated compared to the other apps I used which were light-weight and used the cloud in a meaningful way. This made me want to redefine what a development environment was. I wanted to build something that enabled developers to build across a variety of platforms, and now that cloud connectivity was ubiquitous for developers, it was possible.

I left Microsoft in pursuit of a company that would allow me to chase my crazy idea, and Telerik is just that crazy (talking to you Forte). I didn’t want to build just another IDE. I wanted to build something different; I wanted to build an ICE – an Integrated Cloud Environment. I believed that we could improve cross-platform development by decoupling the gestures of writing code from the platform dependencies required when building apps. Specifically I wanted to decouple coding from the big, bloated SDKs that limited the development experience to one where the coding environment and the target environment required affinity.

The primary objective in building an ICE was to enable developers to build apps that targeted any relevant platform from any development. My theory was that we could extract the SDKs from the local coding environment and turn them into cloud-based services that could still function as part of an integrated workflow for developing apps. In other words, it still had to be an integrated development experience, and the cloud – not your OS and RAM – would become the enabling technology. The experience had to be functional, capable and simple. The age of having to master multiple complex development environments and SDKs is coming to an end. The new ICE age will usher in a new type of development tools, and the dinosaur IDEs will die off soon enough.

Welcome Icenium

Icenium™ is the realization of that vision. Icenium combines the convenience of a modern coding environment with the power and flexibility of the cloud to manage platform dependencies. Icenium enables you to build applications without being limited by the development environment having to be compatible with the run-time environment (e.g. Mac OS X to iOS). It enables you to focus on the content of your application without the headache of managing multiple SDKs and development environments. With Icenium you can use Windows, Mac OS X, Linux, or even device operating systems, like iOS on an iPad, to build hybrid applications that are distributable through the app stores, and run natively on iOS and Android devices.

I believe web developers are looking for ways to move from mobile-optimized web sites to building apps that run on devices, so we built Icenium with web developers in mind. We leverage Apache Cordova (aka PhoneGap) to enable you to use HTML, CSS and JavaScript to build your application. When your project is compiled, we build the iOS and Android native bits in the cloud, which means you don’t have to think about SDKs, Objective C or Java. Just focus on your app and leave the platform dependencies to us.

We also tailored the development experience to web developers. Most web developers (me included) prefer to work with capable, text-based code editors (and not WYSIWYG tools that modify your code without your consent), a browser and some debugging tools, such as WebKit Inspector, so we designed Icenium to work the same way. The Icenium coding environment is a simple text-based code editor, packed with advanced capabilities including syntax coloring and formatting, real-time error detection, refactoring, code navigation, and more.

Each development client (Icenium Graphite for Windows and Icenium Mist in the browser) includes a device simulator that enables you to test your application much like you would test a web app in a browser. The device simulators include options for simulating iPhone, iPad, Android phone and Android tablet, including a geolocation simulator and the ability to rotate and flip the device. The device simulators expose the ability to use WebKit Inspector-based debugging tools – the tools you already know. We have tried to replicate the working style you already use for web apps, making the transition to mobile application development simple and intuitive.

Icenium Graphite™

Graphite Code Editor with Error Detection — Icenium Graphite with real-time syntax error detection.

Icenium Graphite is an installable development tool for Windows operating systems. It is a WPF app that provides you with the ability to build a cross-platform mobile application, test it in a device simulator, build the app (in the cloud of course) and deploy it to multiple devices at once. When you are ready, you can switch to a “release” build setting, add your icons and splash screens and package your app for publishing to the Apple AppStore or Google Play.

Icenium LiveSync™

Icenium LiveSync is one of the truly magical features of Graphite. With LiveSync you can build and deploy your app to one or more iOS and Android devices with nothing more than the click of a button. Your app is built in the cloud, and then delivered back to Graphite where it is pushed over USB to all connected devices.

I usually have 10 or 11 connected at once, including iPhone 4S, iPhone 5, iPad 1, iPad 3, Google Nexus, Google Nexus 7, Galaxy S2 Skyrocket, Galaxy S3, Galaxy Tab 8.9”, Galaxy Note 10”, HTC One X, and the Kindle Fire.

After the app is on the devices you can test it out and see how it works on different screen sizes and pixel densities (e.g. Retina display), not to mention different form factors (phone and tablets). If you want to make a change, simply add, edit or remove the HTML, CSS or JavaScript in your project and click “Save.” When you do, the changes are saved (in the cloud of course) and immediately pushed down to the running app on all connected devices. That means you can work in rapid iterations and see your changes on the devices in real-time, as you make them.

Icenium Mist™

Icenium Mist is the browser-based sister of Graphite. Mist provides nearly all of the same functionality as Graphite, and works on a variety of platforms. I use Mist on my MacBook Air, and even on my iPad, when I am away from my office. Mist also includes the modern conveniences of Graphite, such as syntax coloring, statement completion, and version control integration, as well as a browser-based device simulator that can render your app on an iPhone, iPad, Android phone and Android tablet.

Since Mist is browser-based, it doesn’t have access to deploy apps to devices via USB. Instead, you can build your app and deploy it to a device by downloading the app and pushing it to your devices manually, or simply scan the on-screen QR code and the app will be downloaded to your device.

LiveSync On-Demand

Whether using Graphite or Mist, we’ve included the option to use LiveSync in an “on-demand” way. If your app is on a device and either you’ve disconnected it from USB (when using Graphite) or you deployed the app manually or with a QR code, you can request an app update easily and the content of the app will be refreshed based on your latest saved changes in either Graphite or Mist. If it’s an iOS device, simply press three fingers to the screen for a couple seconds and you will see the download begin. If it’s an Android device, simply press the context menu and the download will begin. LiveSync on demand means you can see your changes on any device, anytime, anywhere.

Icenium Ion™

iPhone_4S_Vert_Ion — Icenium Ion enables you to forget about device provisioning during development.

If you’re familiar with Apple’s iOS development model, you know that in order to deploy an app onto an iOS device you need to first provision that device through the Apple Developer Center. Icenium fully supports working with provisioned devices – in fact Icenium can aid you in creating the Certificate Signing Request required when requesting a device provision. However, if you want to try out your app without provisioning your phone, or you want a stakeholder or beta tester to try out your app and give you feedback, then Icenium Ion is the tool you need. Ion is a development and testing utility (downloadable for free from the AppStore) that enables you to load your app onto any iOS device regardless of whether or not it has been provisioned. Simply scan a QR code provided by Icenium and the app will download and launch inside Ion. Of course, LiveSync on demand works perfectly with Ion too.

Version Control

Of course a development tool wouldn’t be complete without integrated version control, and a cloud-based tool better integrate with popular cloud-based version control systems, so we did just that. By default all Icenium projects are connected to an integrated Git repository in the cloud, and you can optionally configure your project to use any URL-based Git repository, including GitHub and BitBucket. Both public and private projects are supported, enabling you to collaborate and version your code safely.

Kick the Wheels (for a while)

As I mentioned, today we have released Icenium for everyone to use. In fact, I don’t want there to be any barrier in your way to trying out Icenium, so I decided to make it free for the next 6-months. We won’t begin charging anyone for Icenium until May 1, 2013. So go to Icenium.com, create an account and start building cross-platform mobile apps today. I’ll bet you can build an app faster than it takes to download xCode.

Telerik Interview Series: Doug Seven at TechEd 2012

While at TechEd 2012 NA I had the pleasure of sitting down with Richard Campbell of the Tablet Show for a short discussion on some of the exciting technologies being talked about, and my thoughts on cross-platform mobile development.

Telerik Interview Series: Doug Seven at TechEd 2012
– YouTube

Telerik’s Q1 Release is Coming!

Registration for Telerik’s Q1 release webinar week is now open! Does this seem a bit early to you? If it does you are very observant, the release is coming out one month earlier than usual (we are shifting our releases based on your feedback…see, we really do listen).

It’s time for all .NET Ninjas to sharpen their skills! The latest Telerik release is just around the corner and we have tons of new stuff to show off. If you are eager to see the new bits and sharpen your .NET skills, be sure to sign up for Release Webinar Week. This 3-day event is packed with hour-long webinar sessions on the coolest new features shipping with the Q1 2012 release. Release Webinar Week will be held on February 20^th – 22^nd, so mark your calendars. One lucky winner from each webinar will leave with a Telerik Ultimate Collection license worth $1999. To enter the drawing and participate in the Q&A session, you must attend the live webinar.

Registration Link: http://www.telerik.com/support/webinars.aspx

A bad picture is worth a thousand long discussions.

While here at Build I’ve been in lots of conversations with customers, other attendees, Microsoft MVP’s, Microsoft Regional Directors, and Microsoft engineering team members. One of the recurring topics that I’ve been talking about ad nausium is the “boxology” diagram of the Windows 8 Platform and Tools (shown here).

Now let me tell you, I have drawn a lot of these “marketecture” diagrams in my time and its not easy. These kind of diagrams are never technically accurate. There is simply no easily digestible way to make a technically accurate diagram for a complex system that renders well on a slide and is easy to present and explain. The end result is that you create a diagram that is missing a lot of boxes – missing a lot of the actual technology that is present in the system. Unfortunately that is exactly what has happened here – the Windows 8 boxology is missing some of the actual technology that is present.

One of the conversations that has come up is around the missing box in the “green side” (aka Metro style apps) for the .NET Framework and the CLR. Do VB and C# in Metro style apps compile and run directly against the WinRT? Is this the end of the .NET Framework?

Others who have done some digging into the bits are wondering if there are two CLRs. What the heck is going on in Windows 8?

I spent some time with key members of the .NET CLR team last night (no names, but trust me when I say, these guys know exactly how the system works), and here’s the skinny.

Basic Facts:

There is only one CLR. Each application or application pool (depending on the app type) spins up a process and the CLR is used within that process. Meaning, a Metro style app and a Desktop Mode app running at the same time are using the same CLR bits, but separate instances of the CLR.
The .NET Framework 4.5 is used in both Desktop Mode apps and in Metro style apps. There is a difference though. Metro style apps use what is best described as a different .NET Profile (e.g. Desktop apps use the .NET Client Profile and Metro style apps use the .NET Metro Profile). There is NOT actually a different profile, but the implementation of .NET in Metro style apps is LIKE a different profile. Don’t go looking for this profile – its basically rules built into the .NET Framework and CLR that define what parts of the framework are available.
Whether a Desktop Mode app or a Metro style app, if it is a .NET app, it is compiled to the same MSIL. There isn’t a special Windows 8 Metro IL – there is, like the CLR, only one MSIL.

A More Accurate Picture

A more correct (but still marketecture that is not wholly technically accurate) would look like this:

In this diagram you can see that the CLR and the .NET Framework 4.5 are used for C# and Visual Basic apps in either Desktop Mode apps (blue side) or Metro style apps (green side). Silverlight is still only available in Desktop Mode as a plug-in to Internet Explorer (yes, out of browser is still supported in Desktop Mode). Another addition in this diagram is DirectX, which was strangely absent from the original diagram. DirectX is the defacto technology for high-polygon count applications, such as immersive games. DirectX leverages the power of C++ and can access the GPU.

This biggest confusion, as I mentioned, has been around the use of the .NET Framework across the blue side and green side. The reason for the, as I call it, .NET Metro Profile is because the Metro style apps run in an app container that limits what the application can have access to in order to protect the end user from potentially malicious apps. As such, the Metro Profile is a subset of the .NET Client Profile and simply takes away some of the capabilities that aren’t allowed by the app container for Metro style apps. Developers used to .NET will find accessing the WinRT APIs very intuitive – it works similarly to having an assembly reference and accessing the members of said referenced assembly.

Additionally, some of the changes in the Metro Profile are to ensure Metro style apps are constructed in the preferred way for touch-first design and portable form factors. An example is File.Create(). Historically if you were using .NET to create a new file you would use File.Create(string fileLocation) to create the new file on the disk, then access a stream reader to create the contents of the file as a string. This is a synchronous operation – you make the call and the process stalls while you wait for the return. The idea of modern, Metro style apps is that ansychronous programming practices should be used to cut down on things like IO latency, such as that created by file system operations. What this means is that the .NET Metro Profile doesn’t provide access to FileCreate() as a synchronous operation. Instead, you can still call File.Create() (or File.CreateNew()…I can’t recall right now) as an asynchronous operation. Once the callback is made you can still open a stream reader and work with the file contents as a string, just like you would have.

Ultimately all of this means that you have some choice, but you don’t have to sacrifice much if anything along the way. You can still build .NET and Silverlight apps the way you are used to, and they will run on Windows for years to come. If you want to build a new Metro style app, you have four options to choose from:

XAML and .NET (C# or VB)You don’t have to giving up too much in the .NET Framework (remember, you only give up what is forbidden by the Application Container), and you get access to WinRT APIs for sensor input and other system resources.
XAML and C++You can use your skills in XAML and C++ in order to leverage (or even extend) WinRT. Of course you don’t get the benefit of the .NET Framework, but hey….some people like managing their own garbage collection.
HTML and JavaScriptYou can leverage the skills you have in UI layout, and make calls from JavaScript to WinRT for access to system resources, and sensor input.
DirectX and C++If you’re building an immersive game you can use DirectX and access the device sensors and system resources through C++ and WinRT.

Hopefully this adds some clarity to the otherwise only slightly murky picture that is the Windows 8 boxology.

Don’t forget to check out Telerik.com/build.

I know what you’re thinking, and you’re wrong.

Its day 2 of the Microsoft Build conference, and if you’ve been keeping up with the hype you are probably thinking that you need to throw away that WPF or Silverlight app you’re building and start fresh with HTML5 or this new XAML that is the future. If that is what you are thinking, you are wrong. Everything you are doing today you should keep doing. The world didn’t end for you, and your job is not at risk (at least not because of this!). As a .NET junkie going back to the first pre-beta release of the ,NET Framework at PDC 2000 (it was called NGWS back then), and as the former Director of Product Management for Visual Studio, I can tell you that I am comfortable with how useful my skills, and my existing code will be going forward. I am also confident in the value of Telerik’s controls and tools in the future – clearly I knew enough of what was going on with Windows 8 and Visual Studio before I accepted the position of Executive Vice President at Telerik. If I am confident enough to bet my the livelihood of my family on it, you should also be confident in your skills and your existing code and projects.

I’ve also been talking to a lot of attendees at Build, and hearing from a lot of Telerik customers via Twitter and email. There is a lot of concern about the future of the technology we are all using today – specifically WPF and Silverlight. How do these technologies work in the Windows 8 world, and how different is XAML in Windows 8.

First things first, let me help clarify a bit of what Windows 8 is all about. The way to think about it is as though there are two completely different runtime environments….because there kind of are. On one side there is the new Metro style app models that run on the new Windows Runtime (WinRT) and on the other is what is being referred to as Desktop Mode running on the CLR, Win32 and/or IE. Here is the diagram that Microsoft presented.

In this diagram there is a green side (Metro style) and a blue side (Desktop Mode). While it is not depicted here, there is a big fat solid wall in between the two sides. That which runs in the green side, cannot run in, nor access anything in the blue side, and vice versa. Apps you build for Windows 8 are either Metro styled apps or Desktop Mode apps. There shall be no comingling. This is a great design. Some apps should never be Metro styled apps, and some apps should ONLY be Metro styled apps.

Metro style apps run in an Application Container that enforces some security constraints and limits access to some system resources. This enables them to be interesting and engaging apps, with access to some identity services and other appropriate resources, but still have limitations that protect the end users. Desktop Mode applications don’t run in the Application Container, and have all the system-level access available to you today depending on how you are building your applications (e.g. .NET and trust levels, or Win32 and system level APIs).

The greatest example of the right use of Desktop Mode not talked about this week is Visual Studio 11 (yes, VS11 was talked about but no one pointed out why it is not a Metro style app). Your dev environment is not a touch-centric, sensor aware app that you’ll run on a small form factor. It is a powerful app that will need access to many system resources and is best experienced with a mouse and keyboard (and preferably more than one high-resolution monitors). Metro style apps are intended to be touch centric, sensor aware, single screen apps that will likely run on smaller form factors more often than a desktop or laptop PC (in fact we were thinking about calling these apps ‘NISA apps’ – Natural Interface, Sensor Aware apps….we canned that idea).

Just like Visual Studio is a ‘Desktop Mode’ app, so will be many of the apps you write. This isn’t to say there isn’t an opportunity for you to write a killer Metro style app, it just means you need to think about the user experience you want to enable and choose the app model that is best for your goals.

As you build applications between now and whenever Windows 8 ships, and beyond, chances are that unless you’re building an immersive, sensor aware app (like a device centric app or a game), or a rich content experience (like a magazine) you will still be targeting Desktop Mode. All of those business apps will still be Desktop Mode apps, and if that is the case, your use of WPF or Silverlight (including Telerik controls) is safe. All of that code you have today will run in Windows 8 Desktop Mode.

To be sure, I spent some time today with some of the folks that build the .NET CLR. They confirmed this to be true, and we spent some time talking about their Pri-0 commitment to not impact existing .NET Framework applications so that they will run in Desktop Mode.

Metro style apps are different. There is no support for Silverlight nor WPF for Metro style apps. And frankly you don’t need it. What you do need is controls and components that are compatible with the new XAML model for Metro style apps…and Telerik will deliver. We will begin working immediately on making our controls work in the new Metro style app model (in fact today @worksonmypc showed one of the Telerik demos running on the Windows 8 devices handed out at Build). In the future you will have a toolkit that includes Telerik Desktop Mode controls and Telerik Metro style controls. in some cases these will be the same or similar experiences, but we will also deliver to you Metro style controls that take advantage of all that the new app models offer, such as smaller screen resolutions, touch, accelerometer and other sensor inputs.

The one thing I haven’t addressed is the roadmap for Silverlight, and that is because Microsoft hasn’t shared anything beyond SL5, which is currently in RC. It is unclear whether or not there will be an SL6, but this I know – there will be an SL5, and it will have a 10-year support lifecycle. You can safely invest in Silverlight now, knowing that that investment will be supported for longer than the app will be useful, and Telerik will continue to make compelling UI controls for Silverlight as long as enough people want to use that platform.

Technology changes like what we are facing now take a long time to get to ubiquity. People are still using Windows XP (over 40% of all Windows usage is still Windows XP) and people will be using Windows 7 for a very long time. Even as people move to Windows 8 they will still live in Desktop Mode most of the time, except when they are using a tablet form factor. My advice…keep doing what you are doing, and invest 20% of your time in learning about Windows 8 and the Metro style app models. We’ve got a while before Windows ships, and a while after that before it becomes the most used version of Windows.

Build: Day 0

Here I am at the Starbucks in the Marriott Anaheim, which is connected to the Convention Center where Build will take place beginning tomorrow. Already people are milling about and I’ve seen a few friends and former colleagues (in fact, Dave Mendlen, my old boss, and the new CMO for DevExpress, gave me a ride from the airport). There’s a bit of buzz in the air, but also still a lot of uncertainty.

With all of the leaks there have been, it seems the more connected people have an idea of what will be said tomorrow, although they are still unsure what it will really mean. It seems the confidence in Microsoft will not come from them getting into the touch-centric user experience model, nor from a light weight, long-battery life tablet/slate form factor (such as implied by the Windows 8 on ARM announcements at the last CES). The confidence will come from implementation. How well can Microsoft enter this space, or how badly can they mess it up. Those seem to be the two camps.

A lot of folks I have spoken with don’t think Microsoft has the ingenuity to get into this game the right way. Perhaps its from years of tablet devices that were merely laptop PCs that could be used with a stylus. On the goos side for Microsoft, that means the bar is relatively low – simply don’t screw up and whatever else you do will be acceptable.

On the other hand, I know a number of people who believe Microsoft is going to do what Microsoft historically has been good at – enter late and envelop the market. We’ve seen this with the OS wars of the early to mid 90’s, the browser wars of the late 90’s and even the game console market in the 00’s. Unfortunately we have yet to see this with the smartphone market, where Microsoft is still effectively in last place.

Personally I am a believer. I think we will see and hear things tomorrow that will wow us, make us curious, and inspire us to learn a new way of programming for the Microsoft stack. I am not without concern, however. There are plenty of ways Microsoft can mess this up, but I don’t think they will. I believe that Sinofsky and the Windows team have been working diligently to make a compelling experience for Windows developers, such that it may even do what they want mosts, and attract non-Windows developers to the platform. I also think the Developer Division has been working hard to create a compelling tooling environment for the platform. I think most people will be happy with what they see….it just may take a few days.

Telerik is here at Build, but we are here mostly as attendees. We are hear to hear from Microsoft and learn from Microsoft. Our goal is to provide great additions to the Microsoft development tools, through UI controls, additional productivity tools, and whatever else may be appropriate. Of course we could come to Build and totally blend in, so if you are here, look for us and ask for a t-shirt. In fact, Tuesday morning, look for me driving the .NET Ninja Mobile (a Lamborghini with the Telerik logo) and take and post a picture of yourself with me and I’ll give you a t-shirt and a coveted pass to the GeekFest party on Thursday. If you need a ride to the conference Tuesday morning, send me a direct message on Twitter (@dseven) and I’ll come pick you up and drop you off in style.

Product Positioning 101

The past two days in my new job have been a whirlwind. We’ve been in a 2-day leadership summit spanning all of the existing product groups, and the marketing and evangelism teams. During the conversations one of the topics turned to product positioning. Not because Telerik has any particular issue with positioning, but rather because, as the company grows there is some concern about how we can keep the positioning and messaging of both the company and the products consistent as our customers engage with different team members across the various divisions, including our marketing material, website, team member engagements at events, and customer interactions with our sales and evangelism teams.

This is not a unique problem to Telerik or even to small growing companies. I wrestled with this at my last job overseeing a large product (Visual Studio) at Microsoft. This is a pain felt by anyone responsible for a product, a product line, or ever their company positioning. Not a new problem and easily addressed with some conscious work to create a positioning and messaging document. This will be the touchstone for anyone that will talk about your product. It will inform them of how to position the product in the market, and provide the specific messages (talking points) to use depending on the context of the conversation.

Typically you would want to create the positioning statement (the primary component to your positioning document) early in the product development phase. As it turns out, that is exactly where my new product division is – the concept has been proven and demo’ed (which is what drew me here) and now it is time to create a product and a business. For me it’s about applying the basic structure for product positioning, which has been around ever since Eve tried to convince Adam to eat an apple.

A product positioning statement has four main components – the target, the frame of reference, the differentiation, and the reason(s) to believe. Allow me to elaborated.

THE TARGET
The target is who the product is for – who is the target user or customer of the product. The key to a good target definition is to balance being specific with being concise, you need to describe the target well enough that they can be identified, without being so verbose that your positioning statement goes beyond one or two sentences. Using the Adam and Even example, the target for positioning the apple is “hungry men willing to be adventurous with their palette” (after all, Adam had never had an apple before).

THE FRAME OF REFERENCE
The frame of reference is the known object or subject area that The Target can refer to in order to understand what the product is. Before the TV there was little or no easy comparison, so the frame of reference may have been something like “an entertainment device that blends the in-home enjoyment of radio with the visual stimulation of live theatre.” For the apple referenced above this may be something as simple as “a natural snack food.”

THE DIFFERENTIATION
The differentiation is the thing or things that set your product apart from similar offerings from your competitors (let’s face it, if there is no differentiation then there is no reason for a customer to choose your product over a competitor). The differentiation can come in may forms – feature deltas, price, quality, support, social acceptance, etc. For example the differentiation of a Sony TV and Samsung TV may be Sony’s reputation in the electronics business, or their track record of performance, since both TV’s likely have the same features. Samsung’s differentiation my be price (Sony is likely to charge more for their reputation). Going back to our apple, the differentiation may be that it “is sweeter and juicier than any other fruit in the land.” Of course, that a big claim – and that is what differentiation is, nothing more than a claim – and it needs to be backed up.

REASON(S) TO BELIEVE
The reasons to believe are the proof points to back up your claims of differentiation. For example you may claim better quality than your competitors, and now you need to provide the reason to believe you, which may come in the form of independent analysis (e.g. JD Powers & Associates Award). The reasons to believe should help your customer believe the claims you are stating to be fact, not simply your opinion. For the apple, it may not be about independent verification (since there was no one to verify it except for what my daughter refers to as the “sneaky snake”), but rather a believable piece of evidence, like “it was grown in the most fertile soil in the land – the Garden of Eden.” While this isn’t specifically proof that the apple is “sweeter and juicier than any other fruit in the land,” it is believable that the Garden of Eden would produce better fruit than anywhere else.

Once you’ve gone through the effort to define the four components, you can pull them all together into something like, “For hungry men with an adventurous pallete, the apple is a natural snack food that is the sweetest and juiciest in the land because it is grown in the most fertile soil in the land – the Garden of Eden.”

Clearly this is a simplified example, but the format and components are time tested and proven. Once you have your positioning statement you are ready to move on to defining the specific messaging that goes along with your product (how will everyone in your company talk about your product).

I’ll cover messaging next time.

Goodbye Microsoft. Hello Telerik.

If you keep up with me on Twitter you know that last Friday was my last day at Microsoft. I joinned Microsoft as a vendor in 2004 after I sold my company (dotnetjunkies.com) – I was hired in to fix a broken community program that dotnetjunkies had been part of, and a few months later accepted a full-time position to implement the supporting infrastructure. It was my second tour of duty (my first was in 1999-2000, where I met my dotnetjunkies partner). Over the past seven years I was fotunate enough to have some great experiences running a development team, and owning the product management of one of the most successful and widely used IDEs on the planet, Visual Studio. Itwas a good run, but it was time for a change.

Today was my first day as an empployee of Telerik – whom I believe to be a fantastic company that is doing some very innovative work, and working in a very agile way. While today was uneventful (travel day from Seattle to Boston for my onboarding and a management summit), it was a good day. I spent a lot of time thinking about what is to come. About the excitement the coming months and years will bring. I thrive in fast moving, agile, start-up style environments and expect that the culture at Telerik will suit me well.

There is of course an immense pressure that I feel as well – I supose anyone transitioning jobs, especially after seven years, is likely to feel a sense of pressure to prove themself quickly. My hope is to balance that pressure with the common sense to not try too hard too soon. A friend of mine gave me a book a while back – The First 90 Days: Critical Success Strategies for New Leaders at All Levels by Michael Watkins. This is a great (and short) read for anyone moving into a new leadership postition either in a new company, or a company you already work at. The cornerstone is to understand why you were brought in, and implement a matching strategy for the first pivitol 90-days. The wrong strategy, while successful in another situation, could spell dissaster. The right strategy – one that matches the purpose for you to move into the role – should yield good or better (potentially stellar) results.

As I embark on my first 90-days, I plan to share what I can. Telerik has a reputation for being very connected to the community, as I have been for over a decade. If you’re interested, then plan to hear from me regularly as I share the amazing work we are doing here at Telerik.