“Why do we make B students sit through the same classes as their brainy peers? That's like trying to train your cat to do your taxes—a waste of time and money. Wouldn't it make sense to teach them something useful instead?

(Editor’s note: Niel Robertson is the founder and CEO of Trada. He submitted this story to VentureBeat.)

I’ve been building venture-backed businesses for over 11 years now. In that time, I’ve seen a sea change in how businesses are put together. Engineering approaches, marketing approaches, pricing, service delivery … they’re all dramatically different than what they used to be.

But what I’ve come to appreciate is that, ultimately, businesses live and die on three simple dynamics: Distributions, network effects and sigmoid curves (s-curves).  Almost all problems (and most opportunities) come from understanding how to take advantage of these functions – rather than fight against them.

Distributions – A distribution is a measure of how tightly grouped something in your business is. For instance, if you plot all of your customer deal sizes in a distribution, you’ll identify some interesting observations. You might see a tight packing around the mean (average), which indicates that most of your deals are about the same size.

You may also see a bifurcated distribution – which means you have two types of customers. (For discussion’s sake, let’s say one has a peak value of $1,000, while the other’s peak is at $100,000). If you find yourself in this scenario, you’re likely heading towards a problem.

 

With a bifurcated distribution you will have to sell differently. You can’t afford to have direct sales reps selling $1,000 deals and $100,000 with the same costs and compensation plans.  A company spending $1,000 and a company spending $100,000 may each be spending the same percentage of their revenue on your product, but you can’t service them the same way because your earnings relative to their service costs is vastly different. Therefore, maybe it’s time to change your marketing (or selling) focus to one type of customer or another.

Another way to think about distributions is how to move the mean up – or, in other words, towards more value. If you can control where the mean falls by making some changes to your business (i.e. pricing, compensation plans and marketing targets), you can greatly increase the value in your business without increasing the cost.

Sigmoid Curves (S-Curves) – S-curves are everywhere in your business. They describe your ability to scale and where various approaches will break down. You can take almost any example and run it through a sigmoid test.

 

With paid search, if you plot conversion volume (your number of sales) versus conversion cost (the cost of each sale) – it will always result in a sigmoid curve. This simply means at some point the cost to get one more sale will go up dramatically using paid search; you won’t be able to get another cost effective sale simply because you’ve tapped into practically everyone that is looking for your product on Google each day.

S-curves can also describe the scalability of processes and the necessity for automation. For example, if you manually handle customer service issues, you should expect at some point that a customer service rep can’t handle any more customers without some form of automation or process change. This is bad for your business because it means you’ll have to linearly scale customer service reps with the number of customers you have. (We’ll come back to linearity in a second.

Network Effects – Network effects are a beautiful activity if you can find them because you create value exponentially in your business by increasing the value for each customer with the addition of each new customer.

 

The classic example is the telephone system: for each new phone added to the telephone network there is someone additional that any existing customer can call. A more contemporary example is dating sites. For each new person signed up to a dating site, an existing person might now have access to a soul mate match that wasn’t there before.

eBay provides a different example. Each new product added to the eBay market doesn’t necessarily add value to me as an eBay shopper directly (I may not want to buy antique tea cozies), but it creates a positive cycle of attracting more buyers (who do want tea cozies) and thus more sellers who might in the future sell something I want. The network effect is that each member of the market drives growth for both sides of the market.

The last business I built, an enterprise software company, had basically no network effect. That’s a tough slog. Your only hope is to build a large customer base and then mine them for new revenue streams by introducing new products.

The counterpoint to all of this is that linearity is the enemy in any business. You don’t want a sales model that is linear forever (each new sale takes as much effort as the last one) – and you don’t want a support model that is linear (I need a new customer support rep for every 10 customers).

While you can still find businesses that are highly profitable and very linear, it takes time and money to grow those businesses to scale. Professional service businesses are the epitome of the linear approach. If you want to double your revenue, you have to double your staff.

Sit down with your team and walk through all the aspects of your business. Identify the linearities and see if you can come up with some creative ways to turn these into exponential growers. Look for the s-curves and understand where you’re going to cap out in your ability to scale. And look at the distributions and figure out where you can make choices about focus that allow you to cluster your activity and then move the mean towards value.

 

Very applicable to product managers

Read the full article on http://www.uxmag.com/design/the-dirtiest-word-in-ux-complexity

Chances are you've come in contact with a piece of flat-pack furniture from Ikea. You may even have put a shelf or desk together with the help of an allen wrench and a single-sheet instruction manual. Ikea has successfully innovated in pricing, logistics, packaging, and store layout to become a global phenomenon.

But the lesson we, the UX community, can learn from Ikea isn't directly related to their low prices, or making customers put products together themselves. Rather, the valuable lesson we can take from the self-assembly giant comes from an earlier point in a product's lifecycle: the design stage.

When it comes to design, Ikea is a price-first company. Sure, they pride themselves of their Scandinavian design and ingenuity, but above all else they want their products to be as affordable as possible. As a result, the target price for a product defines and constrains the product design, rather than the other way around. Instead of specifying a product and then determining how much it will cost, Ikea decides how much a product should cost and then designs it to fit within the cost constraint. In an interview with CNET, Ikea product developer June Deboehmler said, "When we decide about a product, we always start with the price... Then, what is the consumer need?"

To some this may seem like a counter-intuitive approach. But in actuality, creativity loves constraints. It may seem that a cost constraint would be burdensome to designers but in fact it helps focus and guide their work. Even if cost isn%u2019t the leading constraint (as it is with Ikea), it%u2019s always a critical constraint that should be factored into design.

But in the world of software and UX design, you seldom see projects where cost is treated as a primary, initial constraint. Instead, cost is treated as something that%u2019s derived from scope. Foundational problems with scope, budgets, and constraints are a setup for failed projects and poor UX. But how can we all learn from Ikea in a way that makes sense to industry? We have defined four lessons that will guarantee smoother projects before they even start.

1. Cost is a primary constraint

After they%u2019ve outlined a product%u2019s scope, most companies already have a strong sense of what they think the product should cost, or at the very least how much they can afford. But, in the majority of cases, rather than communicating both the scope and cost expectations to their vendor or internal development team, they withhold the cost information. This forces the development team to go through a complicated, error-prone process of trying to extrapolate a cost estimate from the scope. This is followed by a back-and-forth of discussion until the estimate comes into alignment with the original cost expectation. The cost expectation (or limit) was known all along but everyone has to participate in a ritual dance before it%u2019s disclosed.

In most other settings, this practice would be considered dysfunctional, and an example of how poor trust and communication wastes time and money. But, oddly, it%u2019s standard practice in software and Web development. If the cost expectation is fixed and present from the beginning%u2014in other words, it is a primary constraint%u2014why not simply let the development team know about it? Constraints give the team better understanding of what will be possible, reduces errors in their projections, and gets them working sooner.

Companies are generally wary of sharing their budget numbers upfront for fear of having the development team take advantage of their trust. Their concern is that the development team will charge the full amount in the budget even though the scope of the project should actually cost something less. But, in actual practice, this can't happen because the scope is never smaller than the budget. For innovative, UX-focused product and website development efforts, the project's requirements will always grow as large as the budget will allow%u2014again, cost is the project's primary constraint. The entire course of a project always entails an ongoing negotiation between the stakeholders and the development team about how much work can reasonably be accomplished, and how many requirements can reasonably be fulfilled, before the budget runs out. This is true whether or not the budget is initially disclosed, and whether the project is charged fixed-bid or hourly, because of the weaknesses of upfront planning and the ambiguity inherent to scoping documentation. If the development team is aware of the real cost constraint from the outset, their projections about what they can accomplish will be much more accurate%u2014and, often, much more ambitious%u2014than if they were left to make guarded guesses about what the cost constraint might be.

2. Goals are more important than specs

Initial scope and specifications documents are a form of guesswork product design often done by whoever owns the project, rather than by actual product designers. Such documentation is meant to serve as the definitive blueprint for the project, but have you ever (seriously, ever in your life) seen an early scoping document that turned out to be anywhere close to accurate when the project was done? This isn't because the people drafting these documents are incompetent; it's just that product design is something best left to, well, product designers.

And even for the most experienced product design professionals, the beginning planning stages of a project are the time when the least is known about what the project will actually entail. This is the worst time to have to lay out definitive specifications for the product. Complex, UX-focused software projects just don't lend themselves to extensive upfront planning and specifications efforts%u2014too much of the project's actual needs won't be discovered until design and development commence. So how, then, can project stakeholders ensure their vision and requirements for the product are met? By expressing their needs very clearly in terms of the business' goals for the product. Goals are another form of constraint.

When business stakeholders attempt to build detailed specifications up front, they are attempting to extrapolate specific requirements from their general goals. If Ikea took this approach in their product design, businesspeople would spend a week in a conference room trying to describe in words in long, numbered lists, exactly what a chair or table should look like and what features it should have. This would obviously be silly; product requirements (for both furniture and software) are best expressed through design materials and prototypes, not through lengthy specs built by business stakeholders. The stakeholders' role is to clearly express the constraining goals for the product and hand those off to product designers who can begin to design the specifics.

Business stakeholders need to ask themselves, what does it mean for a project to succeed? Is it successful if it fulfills on guesswork requirements built by the wrong people at the wrong time in the project, or is it successful if it meets the business' goals and stays within its budget constraints? Business stakeholders have the clearest understanding of what the company needs the product to accomplish, but the team that will build the product will advise them best on how to meet the goals. Setting clear, high-level goal and sharing the project's budgetary constraint gives a reliable development team the ability to plan accurately, reduce risk, and squeeze the most bang out of a buck.

3. Honesty and trust are mandatory

As we mentioned, many companies refuse to share their budget out of worry that they'll be taken advantage of. If you tell a car salesman that you're willing to spend $30K, he'll try to sell you a $20K car for $30K. If, on the other hand, you keep your budget constraint to yourself, you may drive out with a $20K car and $10K in savings in your pocket. But when shopping for cars, you're dealing with products that have already been built, and you're just picking the one that suits you. But when you're building software or a website, you're building something entirely new with great uncertainty about, and flexibility in, the details of the implementation. The scope of the product is a direct function of its available budget.

It's critical that you be able to work honestly and openly with your development team or vendor. You'll collaboratively manage a project to ensure it fulfills its goals, stays within its cost constraint, and delivers the best value possible. If you don't think you can trust your development team or vendor enough to share your budget with them, then you're working with the wrong team. That lack of trust will undermine the success of the project by crippling your ability to collaborate effectively. You and the development team need to be partners in building a great product, not adversaries who are managing each other as risks. In an adversarial or arms-length relationship, the development team will always be trying to do the least amount of work for the most money. The business stakeholders, for their part, will be trying to take advantage of the ambiguities in the initial scoping documents to get the development team or vendor to do more work for the same price. Both parties will be focused on protecting their interests, rather than working as true partners toward the joint goal of a good outcome for the project.

This partnership with the design team is what Ikea achieves by staying goal- and cost-focused. While it's uncertain what the product will look like, it's never ambiguous what the definition of success is for that product. This business stakeholders and design team are working toward the same goals without needing to keep information from each other.

4. Abandon guesswork for concrete understandings

This guessing game of "what's my budget" is very much a waste of time. Some business stakeholders think they couldn't possibly guess what a project should cost, but in thinking this they're approaching the problem backwards. When it comes to important, high-complexity, UX focused software and website development efforts, the question isn't "what should this cost," but instead "what can this cost?" One needs to have a number in mind%u2014a limit that will constrain the scope and ambitiousness of the project. Giving development teams a pile of guesswork specifications documentation will just get you a pile of guesswork price estimates. What you end up with are unreliable specifications and unreliable cost estimates. By providing development teams with a specific understanding of your cost constraints, you make it much easier for those teams to make accurate projections about what will be possible. This also lets development teams show you other projects from their portfolios that had similar budgets. This, in turn, allows everyone to work from a solid understanding of the cost constraint with a concrete example of achievable scope. Development teams can help stakeholders by providing detailed information about the budgets and challenges encountered in their portfolio projects.

We believe that these four lessons are important to succeed in the high-complexity domain UX-focused software and Web development. Making cost a primary constraint and sharing budgets with development teams may require a shift in thinking by all parties involved. Business stakeholders need to trust the teams they work with, and therefore choose to work with teams that are trustworthy. Development teams need to earn that trust by clearly communicating what they will do with the information and by being honest and transparent about their projections and about project progress once it's underway. And if there's any doubt on either side, you can always say, "Hey, it works for Ikea".

Great presentation about the value User Experience design on business.