Posts Categorized: Teamwork

pastedImage_2

Building a Startup – The “big picture” on your road to success

This is part 3 of my blog series called: “Building a start-up in the SAP HANA space“.

What is considered a “Startup”?

“A startup is a company working to solve a problem where the solution is not obvious and success is not guaranteed”

Neil Blumenthal, cofounder and co-CEO of Warby Parker

Startup or Side Project?

To me, the big difference is your expectations. Generally in a side project, you have little or no expectations of financial reward or success, these projects are a labor of love and something which is intended to help a community or yourself to achieve a  goal. Don’t get me wrong, it could also include financial incentive, like getting paid for your time or materials. A startup is not much different, they too are a labor of love, and command a considerable amount of attention and dedication, however, your goal for the venture is some form of success. This goal is to generate revenue in some shape or form, and often it comes with the pressures of operational overhead, tight release schedules and financial burden.

In my opinion, side-projects which evolve into a startup are the best. Why? Generally side projects are bootstraped by your regular employment, and you spend your spare time working on them, but the great part is that you are not *required* to succeed and have a regular income to sustain your “bad habit” As your side-project evolves, you can decide if you have the required income and  reach to “transition” your project to a startup as it grows.

It will also be evident, when the time is right to transition, because you may have some form of revenue being generated, or you feel you and your project is ready for the next evolutionary step. In doing so you are going to find yourself faced with many challenges and rewards, and much like life, the ups, and more specially the downs, are going to decide the fate of the overall success of your startup.

Below is a description of various stages of a startup lifecycle, we will touch on a few of these in some subsequent blogs:

Discovery

During the discovery stage, startups should be focused on validating whether they are solving a meaningful problem and the potential market share, and impact which is possible. During this time a founding team might be formed, customer interviews conducted and a value proposition is defined. A minimal viable product (MVP) is created and this is a great time to consider joining an accelerator or incubator. You may also consider trying to get some financial support from friends and family or a early stage venture capital company to support your team and visions. Also keep in mind that these the opportunity to pitch your idea to various VC’s can be both positive and negative.

Validation

Your startup should be looking to get early validation from customers, if you have to beg, borrow, donate an organ, or steal these, do it . Every one of your validation contacts are worth their weight in gold. Your goal at this stage is to refine core features, try to gain some initial user growth as well as understand  some key KPI’s which you would like to use to define your startups success. During the validation period is a also good opportunity to consider getting some seed funding and considering building out your team. You will also hopefully gain some paying customers and consider pivoting your product to meet their requirements.

Efficiency

During the efficiency stage, a startup should validate their business model and improve the effectiveness of their customer acquisition process, and avoid losing too many customers in the process. Hopefully by now your value proposition is refined, user experienced overhauled, conversion funnel optimized, and a steady growth pattern is being achieved. From my experience, this is where you start feeling like you are starting to succeed, you have a product which is starting to generate some form of revenue and you often start seeing the direct correlation between a marketing or advertising campaign versus the impact on your customer base.

Scale

During the scale phase, startups step on the gas pedal and try to drive growth very aggressively. This could be driven by a large A Round of funding (or hopefully you have enough in your own bank balance) and you focus on customer acquisition through a ramp up in your sales team. During this stage you brace yourself for load by making scalability improvements, support teams or infrastructure to handle the impact. Hopefully by now your revenue stream or funding has some space for some new executive hires, and you shift your focus from developing your core product to defining some processes to support the product and business services in a structured way.

You may also consider establishing departments and teams within your group to handle some of the administration functions. Starting to sound familiar? If so, it might be time to reconsider that you now have a Company, versus a Startup!

Next Up

Sorry for all the non-technical HANA content in this post, but I really think its important to help you understand where you are, and even more importantly what to expect.

In my next blog post we will chat a bit more about MVP’s (Minimum Viable Product) and we will also look into the SAP Startup Focus program and how it can help you get started and on the path to the first stage of “Discovery”.


pastedImage_0

Building a Startup – Your value proposition and elevator pitch

This is part 2 of my blog series called: “Building a start-up in the SAP HANA space“.

Over the past 15 years, I have developed a variety of applications. Web, mobile, some in the startup realm, some just as side projects, customers projects, partner applications, and the list goes on. Although if there is 1 common denominator across all of them, is that I generally started to write code, before I knew *exactly* what I was going to build. Looking back, I realize why I did this, and generally it was because of all the enthusiasm I had for wanting to make something work, bringing something to reality and showing it *is* possible.

metric² was no different, of course I learned a few things over years, but since I was working with a newer technology, I was keen to get my hands dirty and see what was possible. Before I got started, I put together a list of core features, a technology stack, frameworks to be used, and how it should all be integrated. I thought I was doing things “differently” than before, by starting out with a sure fire plan to develop something which was going to win. But I missed one of the most important topics, my “Value Proposition”.

I think that your value prop should be something that gets “sketched” before you write a single line of code, before you decide what tech stack your app or product is going to be governed by, and before you tell your best friend about your big idea. More specifically, it will be *what* you tell your best friend is your big idea. More often than not, and in my case, my ability to write code, without having a goal in mind causes your “code” or product to define your value proposition which is the wrong way around! It was also extremely difficult for me to blurt out what my application actually was (Just ask Mark Finnern and Phil Loewen), because I wasn’t able to clearly define what my application was to someone. So even though I had written a ton of code, was “pitching” my application and felt like my beta was finished, I went back to the drawing board to try and clearly define my value proposition and what it meant to metric².

So what exactly is a “Value Proposition”?

To me, a value proposition defines what benefit you provide, for who, how, and what makes your service unique over the competition.

Nate Gold once told this story:

The story is told of an unannounced visit by John F. Kennedy to the space center at Cape Canaveral in the mid 1960′s. Kennedy toured the complex and met a man in overalls. “What do you do here?” he asked. The man replied, “I’m earning a living.” Kennedy nodded and moved on. He met another man in overalls and asked him the same question. “I clean away all the rubbish,” the man said. Kennedy smiled and strode on until he met another man in overalls and put the same question again. This time a big smile came across the face of the man who replied, “Mr President, I’m helping to put a man on the moon.”

Nate also suggested that this should be a great example of your Value Prop, I like to think of it as the sum of the parts.

What did I do to create metric² value prop, I sat down and went through the “Hows” of what we do, (which is what Nate suggested), I tried to define what the application or product was trying to accomplish and through what means, and I came up with the statement below.

Whats the difference between a “Value Proposition” and a “Elevator Pitch”?

A elevator pitch is better suited to what you would say to someone who you just meet and they ask what you do. You say it with passion and pride, and its probably more focused on why you are doing what you do. It may also include your value proposition and add to it, or elaborate on a specific topic.

 

I created this elevator pitch for m²:

metric² is developing a easy to use web based platform making it quick and simple to build predictive, streaming and real-time dashboards helping enterprises succeed through data-driven decisions.

Why are these 2 statements important?

Once I decided what they were going to be, I put them up on my wall in front of my desk and every time I develop, or ideate something for m², I take into consideration whether they fall into category of helping to make these 2 statements a reality.

While it might seem like a no-brainer, I really believe that these are the “small” things which count to keeping you on track when building a product. (or on any project where you get to define the scope). I also believe now, that these 2 statements drive my development on the project versus the other way around.

Whats next?

In my next post I plan to chat a little bit about what a startup is? Whats the difference between a startup and a side-project? And more importantly why does it matter? We will also look at some of the stages of building a startup.


startup-ideas

Building a Start-up in the SAP HANA space

I have some fond memories of a television series from the BBC called “A Car is Born” a 15 episode show where the presenter, Mark Evans painstakingly builds a AC Cobra replica. The show highlighted his experiences, trials and tribulations of building something from the ground up.

At TechEd 2014 in Las Vegas I gave a presentation on being a part of the SAP HANA startup program, developing a product, and trying to make an impact in the world of SAP HANA. While its been an interesting ride, I really felt that my 45 minutes up at the podium was really not enough to convey the past 2 years of highs, lows, successes and failures. Since that was the case, I thought I would get back to some blogging about my experiences along the road, hoping that I can inspire, dissuade and educate others about my quest, just like the BBC show. If you are a budding entrepreneur, HANA guru or just wanting to gain some life lessons (at someone else cost), I encourage you to read on, and share your experiences through some of your life journeys.


“You should never underestimate enthusiasm”

Over the past 15 odd years of my life I have developed a myriad of applications, some that succeed, and others which failed miserably, but in every case on my path from taking the product from inception to reality, it has always been done with such optimism and enthusiasm that even if the idea was mediocre, in my eyes it was a clear winner. Sometimes this “fog” can get the better of you, but in most cases its the drive which encourages you to work late and over the weekends with the intention to build something which is going to be a winner.

Working on metric² was no different. I recall spending multiple hours at TechEd/Sapphire hearing about HANA and its opportunity to change the world, wondering what the true benefit of HANA really was, and it was just not evident to me. That was until a few things changed my perception, I was working at a customer site which had 23 different systems being consolidated into a single data mart for a single report which was run daily. People worked tirelessly to ensure 23 different ETL jobs were processed timely, correctly and accurately to produce 1 measly report, and it struck me that this would be a great use-case for HANA. I started to understand and realize more and more of the benefits, technologies like AFL, PAL, XS Engine, Columnar store, In-Memory, etc. are all clear winners to simplify IT at the foundational level. Once I understood the opportunities, the enthusiasm kicked in, and drove me to work tirelessly on metric² through challenges, time constraints and personal issues to deliver something which I *knew* was going to be a success. Yes, by this stage the fog had set-in.


“Getting started”

Since I had started work on the metric² product on .NET/MS SQL (and had 1 customer live) it made a lot of sense for me to switch the infrastructure and re-build it on HANA. It took a bit of a learning curve, but since I had developed multiple web applications in the past, it was simple and straight forward to get up and running with XS. I also went through the OpenSAP course (from Thomas Jung) which gave me some great fundamental understanding of the core technologies and some opportunities to take advantage of. With my new found understanding and development skills I started down the road of developing metric². Sketched napkins, rough architecture drawings and random emails littered my desk describing how metric² should work, but an important I never quite decided was, what and who metric² was really for, what was my target audience and who would ultimately be my end users? Unfortunately, looking back, this was one of my biggest failures in the project and still is a challenge today.

In my next post I will chat about my 1 new requirement which everyone should have before they write a single line of code: Defining your value proposition. PS. This is relevant for any form of project (Internal, external, customer etc.)