Kick Major Booty: The 10 commandments of being a technology and business change agent/leader

Below is my Top 10 List of rules I've learned over the 15 years building, selling, and implementing web apps.  I hope you enjoy them and learn from the many mistakes and experiences I've been lucky to have!

1. Be different.  Build the thing that's missing; that they don't have.  Don't bore people with products that are way to similar/the same as what's already out there.  Don't be boring, dare to be different!
2. Be business-minded and results-oriented.  Make sure that the thing you build connects very directly to the business context and drivers.  Be serious about business and results.  Only work on the things that pay you and for which the business will get paid incrementally.  Know value.
3. Seek to know the customer's experience.  Clearly understand the numbers and drivers behind the way that all users of the system think and make decisions.  Think about the system from their perspective.  Understand what they need and how they think. Get in their heads.  Watch them.  Interview them.  What makes things easy and exciting for them/better?  What makes them tick?  What would excite/wow them?
4. Test all assumptions ASAP.  Never assume anything but because you will have to, always build toward the things that will rapidly test your assumptions.
5. Never work for free; find a customer 'cause you're good enough.  Make sure that you get paid for what you do; don't spend too much time toiling on free projects or for a customer target who is not very well defined; find a customer and charge them for what you do.  Let them be your "seed" funding.
6. Be a data and process geek.  Map the flow and understand the business and business processes from end-to-end, in gory detail.  Know the edges and the context.  Intimately know the steps, functions, and limitations/constraints/realities.  
7. Lead it like you stole it.  Be a technology/process/business change agent by being that person who can get the right things done rapidly.  Don't feel like you have to do it all *by* yourself but do take ownership and feel like if you're not with me you're against me and I'm going to make this *f'ing* thing happen!  Delegate.
8. Baby steps.  Stay agile and be flexible in changing what you're building if you learn something new.  Don't throw your hands up or get too distracted with shiny objects.  Finish what you're currently working on so it's SOLID, and then move onto the next thing and make sure it somehow connects.  Build bridges.
9. Build strategically.  Make sure you build the feature or product that will get them excited and keep them engaged (have a sales/marketing/process/adoption angle in everything you build).  Have balls.  Don't be a wuss!  Be different!  Consult with the Kano Model to balance what you build and make sure that it's not ONLY bells and whistles!
10. Worship the customer.  Allow yourself to take direction from and fear the customer.  They're always right.  They may not always KNOW, but they're definitely always right.  It's irrefutable.  Above all else, allow yourself to be directed *by* them.  Build for them.  Worship them.  Understand the path you need to put yourself on so that you're laying that path for them so they can walk.  

Clearly Separate the Selling and Delivering Functions

Part of being in the professional services field is selling.  Selling is huge/big/everything.  If it weren't for selling and business development there would be *nothing*.  Okay, maybe that's a bit harsh / too strong.  What I should really be saying it that product and service QUALITY are the number on things that matter.  But when there's trust involved and "strategic partnerships" involved, quality *can* play second fiddle to the relationship.  In fact it should be your preference to have these relationships *so that* quality isn't the only thing.

Contracting is a difficult business.  Contracts will get created and the more clear they are the better the chances are of delivering the right product.  I'm not making an argument here for no documentation, quite the contrary.  What I am trying to do is parse the distinction between two things: SELLING, and DELIVERY QUALITY.

By separating these two things in business we can create great solutions.  By having a sales and selling/relationships context, we can be all about the PEOPLE and RELATIONSHIPS and by having a delivery/quality context we can care all about the PRODUCT and CUSTOMER SATISFACTION.

The responsibilities of the Selling/External Relationships function:

• Meet new people
• Qualify people as good-fit customers
• Maintain relationships and remain "friends" even when things are wacky (but try to be on the side of the delivery organization...this can be a very hard balance)
• Sell new solutions and understand what's being delivered
• Understand "drivers" in the client-organization business
• Lead and manage

The responsibilities of the Delivery/Product organization:

• Exhibit engineering excellent
• Make quality/cutting edge products
• Build for the future
• Be great with your estimates
• Communicate well
• Deliver, deliver, deliver (demo, chunk, and milestone)

In your organizations make sure that you clearly separate and spell these two functions out!

Use companies as incubation hosts - deliver software through professional services projects

There are a million GREAT software ideas.  There are also millions of companies out there who could *greatly* benefit by applying these software applications to their businesses/operations.  But how do these ideas get built/realized and how to companies adopt them?  Professional services organizations like those I want to create.  In this article I'll talk about how things go from "great idea" to "applied prototype" to "service business".  I'll discuss each of these phases and then recommend things you can do to create and sell these types of businesses/organizations.

Great Idea.  In the beginning there's a good idea.  Let's say that our good idea is to provide a restaurant's customers with a "mobile app they can use to order, replacing the wait-person".  The restaurant patrons use their SmartPhones or Tablets to order from the restaurant menu while there.  The patrons launch the restaurant app, pick their location, identify their table, and then start requesting services from the kitchen.  The app would talk to a service that the wait-persons/kitchen staff use to fulfill orders and requests.  They, too, COULD have a mobile app that allows them to see the requests and mark them complete.

Applied Prototype.  The applied prototype phase is when this technology actually works for *a location*.  The basic service has been proved and the value of such a service has been documented as a case study.  For example, the benefits/drivers for this applied service are: order-taking time reduced, improved customer satisfaction with restaurant, and service flexibility.  The case study would measure and promote these items for example:

• 50% reduction in order-taking time (via observation/data study)
• 50% increase in customer satisfaction (via customer survey)
• 50% increase in ease of organizational change (via management survey)

Service Business.  Now that the service exists once and there is a customer who will speak out for its value (and there's a software architecture to support expansion) this can be turned into a business product that is sold repeatedly.  The idea of it can be sold and it can also be marketed through sales channels and propoganda describing the service, it's value and customers.  During this phase, new customers can choose to get the service themselves and the service provider business can offer pricing to integrate and measure the system for that new business.  If they do it well, they will continue to improve the business and value driver effectiveness for the cost.  They will make money.

So...what does all this mean?  How do you go through these cycles?  Some recommendations:

1. Have good ideas and be creative.  Think of things differently and as mobile, connected software services.  Talk to your friends, network, brainstorm.
2. Understand the relationship of the new service to the existing business.
3. Find early-stage businesses who are willing to share in the risk of developing and applying innovative service solutions and helping prove the value of these types of businesses.  (Sell!)
4. Use these organizations to (co-?)finance your operations.  
5. Deliver.
6. Consider sharing in *some* of the future profits with the financier.
7. Gain more customers and traction.
8. Be the entrepreneur, driver, and owner.  Make it happen!

Sell two things: CRM and (Mobile) Apps

I was talking to a friend today about how the main business drivers for people are reducing delivery risk (through project management) and reducing cost, through better efficiency and project management.  I disagreed with him that these were *the* things that mattered to managers.  I posited to him that the following two things matter to people in today's market and economy: CRM systems (sell more, more efficiently) and (Mobile) application development.  I'll discuss these two things in details and then summarize.

CRM systems are very critical to businesses for the following reasons 1) things get messed up when your sales/selling process is messed up 2) if you can clean up your sales/selling process then you are headed in the right direction 3) there are some good systems and processes out there that can help people clean up things.  There are big ROI opportunities here.

(Mobile) App development is huge.  This is a *major* market disruptor right now and will be a major disruptor for business processes in years to come.  People with their smart phones are powerful. They can do a lot.  Building services and apps for these phones is very big business.  Companies want to capture these opportunities and they need help in doing so, thinking about it.  People with experience selling web-based solutions will have a leg up in selling mobile solutions...this is the new wave.

Using either of these two "sales tools" will help organizations have the right conversations with companies about things that matter.  Yes, Sam, we can help companies cut costs and manage their existing operations better, but so what?  Won't it be too late by the time we know?

3 Elements of Delivery

Three

Delivering solutions is complicated because there are three elements that have to work together and these elements can be seen from two perspectives, so really, there are about six things going on in describing this.  But I'll keep it simple.  The major *technology* parts of delivery are:

1. The content management system.
2. The API
3. The App

The two perspectives from which they can be seen are:

1. The user as the company's customers
2. The user as the company's employees

Depending on how we look at the parts, we get different results.  But in general, these are how the parts work and work together. 

The content management system is the part of the solution that the customer interacts with to control the content. This may be company employees and this can be end users (in other words, in one context, this could act as the app itself).  What's happening here is that INPUT is being received and stored in the database for presentation in the app, be that a business intelligence dashboard, or in a customer-facing app for the people (intranet, mobile, intranet, extranet, whatever).

The API is the thing that connects to the database/data store and "gives" the data to the app.  The API also "takes" information from the app and can persist that data as necessary in the data store.  The API's job is to provide a SERVICE that the app can use to get and put information.  The APIs job is to obfuscate the complexity of the database and business rules from the user/developer and give a simple way to interact with business objects / data.

The app is the thing that is awesome and pretty.  It is the main UI/UX that the user interacts with.  It is THE THING.  It is THE BIG THING.  It is the thing that people want to buy, use, and sell.  It is the sexy object of interaction, etc.  Somehow we want this.

My company offers APPS (and these other supporting elements of delivery) on mobile and any other relevant platform: PC, console, intranet, extranet, whatever you want.

Analyst analyzes, doesn't judge

As a developer doing analysis, you have to remember that the goal is to write down what the customer wants.  You are NOT to judge or think about what they're requesting from the frame of mind of the developer.  If they ask for something that you don't know how to do, looks complicated, and that kind of thing, simply write it down and go talk to your team about it and get back to them with an estimate later.  This data-collection phase of "what's requested" should NEVER be a discussion of what's possible/easy/pragmatic.  Separate yourself in this role as the data collector rather than the implementer/judger/decider.  Be a better sales person and never tell them no, or "that's too hard".

Target your job search with multiple versions of your resume

Getting a job in technology isn't easy.  In my opinion this is caused by the complicated and dynamic nature of the industry: very few people know which way's up and how to find the right candidates.  But there's many jobs out there, so how do you get one?  If you ask me, the secret's in creating several targeted versions of your resume; one for each major facet of technology:

• Technical/developer resume.  This resume highlights all of the technical stuff you have done, all of the technologies you have used, and all of the results you've gotten from creating custom solutions for people. Make sure you call out all the technical details and make yourself really sound like a developer.  Speak to your skills from database to middle-tier to front-end and talk about your experiences on teams, developing and being creative.
• Manager resume.  This resume should talk about all of the "business" and management / leadership roles you have done.  Tailor it to only refer to positions where you were a manager.  Remove titles that looked like developer titles.
• Consultant resume.  This is your "all up" resume that points you as a leader and Jack of All Trades.  Tell people how you can work with customers, sell and implement solutions.

Be specific and choose the right resume to tailor when applying for the job.  Your overall positioning will help you feel grounded in what you do best: sell!

Unified Delivery System

Unified delivery approach

Systems suck today at supporting the process of delivering professional services.  I define professional services as services provided to organizations for contract.  This typically includes:

1. Legal contracts
2. Payment
3. The delivered work

In order to create this simple type of transaction, several systems are required to support the process (but I can't find one system that does it all for some reason):

1. Track leads, accounts and opportunities - CRM (SalesForce, Sugar CRM, Sales Force)
2. Estimate and track work - Project Management (MS Project)
3. Invoice and track accounts receivable - Accounting (QuickBooks)

It shouldn't sound to this point that professional services delivery is complicated but for some reason it is.  I have not yet found an integrated system that supports the basic functions highlighted above.  This means that  managers are left to procure many of these systems individually and then *somehow* integrate them.  

It's the integration part that's the hard part, I think.  There's some interesting thinking out there like in Master Data Management (MDM) and the like for doing this in an automated way...but this might be the bleeding/cutting edge.

I'm going to start putting together the pieces -- for myself, my companies, and for resale--the systems required to support and automate the process of delivering professional services.  

Please let me know if you know of good-working, all up system integration.  

The Genius Session

A genius session is a meeting between a customer and the "geniuses" from a consulting company.  In mobile application development, typical types of geniuses are: designers, Android developers, iOS developers, database types, and project/program/product managers.  In general, the sky is the limit in thinking of relevant experts you would want to bring to the table to think out your product or service.

AppsJack offers low cost and high value genius sessions to people looking to get a mobile app or improve the one they have.

Contact AppsJack today to explain your situation and help us think of relevant geniuses for you!

Custom, Generated, Configured

In the mobile application development space there are three main ways to build apps: custom, generated, and configured.  In this post I'll describe each and then discuss their relative merits and pitfalls.

Custom application development is when an app is built for the specific customer needs and the engineering shop makes the app basically "by hand".  They may re-use some components, but in general they are building the thing from scratch.

Generated apps are those built from frameworks like Sencha, Phone Gap, and Canappi.  At AppsJack we like Canappi for its ease of use and comprehensive treatment of functionality from the database to middle tier to front end, be it iOS, Android, or HTML/CSS.

Configured apps are a category of apps like those from Mobile Roadie that are configured.  They basically offer a template that you can use and plug things into.

For customers who are not very price conscious and want the best possible solution, they're going to want to choose a custom application and probably have it generated from a library like Canappi where possible.  For customers who are price conscious and want to plug into a basic app to get in the game, they may think of configured apps like Mobile Roadie.

Whichever type of customer you are, consider using AppsJack to get you the app you want.  We'll work with you to understand your needs and give you the best bang for the buck.