5 new rules for product development

5
New
Rules
for Product Development
Tuesday, September 24, 13

Emerging trends
•i’m going to be chatting about
emerging trends we’re seeing across
our engagements and in the industry
that speak to the new way software
products are getting made.

Pat Sheridan
CEO, Modus Create
@sheridap

Art
becomes
Science
becomes
Engineering

Art
“ART” refers to people in any given field of
practice innovating better ways of working
through necessity and trial and error.

Science
“Science” refers to best practices getting codified
over time, being given names, and becoming
widely accepted standards for the ‘right way” to
get work done.
For Software products I think about the evolution
from waterfall to iterative to agile development as
the maturity from Art to Science.

Enginering
“Engineering” refers to the maturity of these
solutions into patterns, systems, and even
products.
The maturity of tools for test driven development
and continuous integration and products for agile
management as the engineering part.

The
Times
They are
a
Changin’

The Past 5 Years
From Virtualization to Cloud Based Services the introduction of mobile
devices and the introduction HTML5 frameworks and micro-frameworks
all speak to this change
The most striking to me is the speed at which this change has
happened and continues to happen.
The pace of adoption for all of these innovations in the workplace
continues to increase as well.
This holds a lot of promise for what the next five years will bring.

Tipping Point
2010 2015
Today

Tipping Point
It’s not just the core technologies that are evolving
quickly. It’s the ways that engineers work and are
being managed
More importantly ITS THE WAY NON
TECHNICAL BUSINESS folks work and are being
managed.

Tipping Point
These effect of these changes makes for better products, developed more
quickly, by productive (and hopefully happier) developers.
Take take advantage of these changes, as Steve Jobs would say, we need to
think differently.
As large companies struggle to formalize innovation, they are studying
companies like Apple and they’re studying startups with the idea that by
doing so they can incorporate new ideas and new approaches to work into
their day to day business.

1 Embrace the New Stack

Embrace the New Stack
Recognize the future is now. Advancements to
client-side development are just the tip of the
iceberg.
It’s easier than ever today to create amazing
HTML5 user experiences.
But those UIs depend on a robust server side
services deliver content and functionality at an
increasing pace.

Future Stack
We’re are very familiar with Service oriented
architecture and RESTful API development that allow
developers to write less code, or better said, to write
more business value /feature code.
The days of writing and maintaining internal
proprietary frameworks should be put to bed.
It’s taking less and less convincing to show clients they
don’t need to continue to develop and maintain these
home grown and brittle frameworks.

IaaS
PaaS
Cross-app Services
App Services
SaaS
Leverage Cloud Stack

Cloud Architecture
IaaS
•servers, storage
PaaS
•APIs/SDKs, elastic Scaling, Database, Runtime Environments,
Scheduling and load balancing
•Security & Compliance, MDM,, Risk Mgmt, Threat detection,
Anti-virus
Cross-app services
- Cloud integration, USer ID mgmt, Rules & Policy, System and
app management.

Cloud Architecture
App Services
Collaboration, Content, Process, BI/Analytics, eCommerce
SaaS
- Productivity, HR, Finance, Customer Service, Marketing,
Sales, Collaboration
In general, the idea is not to have to maintain and support
are your critical dev infrastructure from inside your building.
And the same goes for the software team itself.

2 - Glocal Teams

‘Glocal’ Teams
“Glocal” means Global & Local.
As the world continues to get flatter through technology, it’s likely your
potential customers could be in any country, speaking any language,
and that the sun may never set on your business.
Your engineering talent should be no different if you want to be best
suited to compete in a global market.
Developers should be an integrated expertise in the product team.
Years of businesses optimizing for low cost development has put
considerable barriers of communication and attitude between business
and technology.
To identify and retain the best talent for your team, you should be
configuring to support multi-timezone developments.

Developers != Resources
To give you an example, Last year we worked on a large scale app for
the UK with developers in timezones from Japan, all over the US, UK,
Netherlands, India, and even Tanzania.
There is a global race for talent. In today’s world having a team
comprised of 1 or 2 developers in multiple cities, can easily outperform
much larger teams in one remote location.
It also enables you to support multiple clients in multiple timezones
with a personal human connection as well.
The collaboration tools are only getting better: from Skype,
GoToMeeting, Google Hangout, Hipchat, web based project
management tools and UX/prototyping tools are making this possible.

3 Platforms over Products

A single product mindset can often be too limiting.
When you focus on developing a platform, you can enable a partner
ecosystem on top of your offering.
Great products focus on providing the most seamless user experience
possible to the end user.
But Increasingly customers want full api access to any SaaS based solutions
they buy so that they can customize and integrate data and workflow
seamlessly into other parts of their business.

In many cases, unique requirements exists across the customer base
that make it hard to build one user experience or feature-set to
anticipate all customer needs.
So how do we handle this dilemma?
We already see this with business apps like Salesforce, Quickbooks,
and Intuit, and all the major carriers are providing entire dev api’s to
encourage robust marketplaces are being built on top of the core
features provided.
I just recently noticed that even Spotify is exposing an API to enable a
custom music apps store within the Spotify app.

Stop Repeating the Past
Hopefully you’ve all seen this cartoon, and
unfortunately we’ve all lived through one of these
kinds of projects in our careers.
Historically, a lack of ‘shared understanding’ in
software projects has led to poorly defined, poorly
managed, and poorly executed failures.

4 Apply Agile to Your
Business

Lean product Dev
So how to we prevent the mistakes of the past? The Lean Startup Methodology offers a path
forward.
The Build – Measure – Learn approach focuses on an almost scientific method for validating
assumptions about what features customers want before writing a line of code.
The best practices of agile are now being applied to the business itself.
Good tech managers realize that engineering is not a black box and that maintaining a shared
understanding across the team is the single biggest risk reducing factor on large projects.
An even worse failure is building a technically great app that no one wants to use.
Many times its up to the development team to advocate, educate, and enforce agile practices on your
business colleagues.

Lean product Dev
Core Concepts of the ‘Lean startup’ Methodology:
• Product Market Fit
• Customer Validation
• Minimum Viable Product
• Vanity Metrics

Lean Startup
The Lean Startup methodology is getting
worldwide attention and create discipline and
accountability on the business to make the best
use of development time and get the right
product to market faster.
Get involved!

Lumberg’s days are numbered.

Lean Startup Machine
LSM is a three day intensive bootcamp that
forces aspiring entrepreneurs and technologists
to “fail fast and fail often”.
All before ever writing a line of code.

Lean Startup Machine
Teams define and redefine their app ideas,
rapidly exploring the problem and solution
space, experiment on solution design prototypes
and validating with real user feedback.
This kind of ‘iterate’ the business idea first
approach is setting new and better expectations
on the business to better confirm idea are worth
building, before committing development time
and money.

Validation Board
At the core of Lean Startup Machine approach is the Validated
Learning Board.
and the main aspects of this approach are starting to be used
by large companies, to get away from the volumes of
documentation of the past, that was more often wrong than
right to begin with.
Customer and product Hypothesis are identiﬁed and iterated
against.
Core Assumptions are identiﬁed and tested with experiments.
and feedback from ‘real people’ is gotten, often on the street.

Agile + Lean
Improvements to the way requirements are identified and documented are
being accompanied by ways to prioritize development work.
How many folks are using agile planning tools like Pivotal tracker?
The primary value from tools like Pivotal is to determine developer Velocity
as a key metric for understanding the pace of feature development.
Pivotal is great for identifying and scoping user stories, but not such a great
job on helping determine which stories to build first.
For that we need something else.

5 Business Weight Your Stories

5 Business Weight Your
Stories
We’re all familiar with story point sizing schemes
from simple ones like “easy, medium, hard” 1-3,
1-5 pts (or “T-Shirt sizing” as some call it), to
more complex schemes like Fibonacci sizing.
At best, these sizing techniques identify
potential risk and complexity in the engineering
work.

5 Business Weight Your
Stories
When done right, this helps development teams stay honest
about estimations (and calibrating estimations at the end of a
sprint).
But to answer Why this feature? or Why now? We need a
business value weighting.
If you think about a product as a self funding effort, then you
need a mechanism to identify the right time and sequence for
building each feature.

5 Business Weight Your Stories
User Experience Weight
– will this feature measurably add value to the customer
experience?
Revenue Weight
– is there defined revenue opportunity associated with this
feature?
-- has a customer asked for it and willing to pay for feature
acceleration in the roadmap?
-- is a deal dependent on closing b/c of this feature?
-- [more likely] has a sales guy already sold that this
feature exists?

5 New Rules
1. Embrace the ‘New’ Stack
2. Build ‘Glocal’ Teams
3. Build Platforms over Products
4. Apply Agile to the Business
5. Add ‘Business Weighting’ to Stories

thanks!
@sheridap

5 new rules for product development

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to 5 new rules for product development (20)

More from Patrick Sheridan (7)

Recently uploaded (20)

5 new rules for product development