What it Means to do Lean Startup

From DevSummit
Jump to: navigation, search

LEAN startup model (BEN, facilitator) aka Optimizing for LOVE, what we’re working on and getting people/users to use and share.

Quick individual shares… themes are users vs. clients, developing tools that people want to use over time, building technology simply and adding only what’s necessary, ideas for making software dev process leaner, integrating user feedback, how to make websites and processes that people like to use, including sharing stories, sharing with community of how to get more engagement with users, new dev models, creating value for nonprofits, learning from mistakes, alternatives to spec it out, build it and they will come…

Vision is primary thing that you’re creating, along w/objectives. Value hypothesis – how users will find value with what you’re creating. Look at metrics, re: retention, to see if value hypothesis is happening. Minimum Viable Product FIRST [absolute bare minimum you can do before writing code/building so all that work doesn’t get thrown out later, e.g., using wire frames instead of long spec document, shorter time frame (4-6 weeks)]. More about real-time interaction rather than building the back end. Rapid test experience of how people interact w/technology. Example: Web Van (bombed).

Involve community members re: new features so they can try out (usability testing). Makes easier for tech team to have this testing beforehand. Core to lean start up processes – an experiment.

Segmented customers/users to get feedback: looked at 3 different audiences (but was challenging to manage).

Rub with funders/foundations about lean approach: why do you need our money? Iteration between small # of developers can happen very quickly – challenge to update and involve funders/grants. Funding dynamic is complex. Some funders get it but often need to push back – have courage to do so.

Can lose big picture when looking at value level for each feature. Contrast optimization vs. vision.

Lean start up is a learning process – initial ideas can change a lot when real guided by vision.

What about nonprofits that can’t afford software development but use already-existing software and customizations.

If data proves value hypothesis WRONG, try something else and engage users more (PIVOT around target groups/audience, methods, financial model). “Your opportunity is to do the most amount of PIVOTS before the $ runs out… [Eric Reis]” Failing is fine, expected, fail faster and do next iteration. Can’t afford not to test.

Many nonprofits are not start ups, esp. re: technology. Nonprofit set of relationships in the community, not just software platforms. Also challenges with financial capacity of nonprofits vs. for profit.

Big pivots vs. small pivots – about adoption. Lots of learning with small pivots. Need to include metrics. User advisors can help w/persistence vs. stubbornness.

What are the metrics for demonstrating impacts/outcomes. Design metrics from the beginning. Examples: satisfaction surveys, surveys to learn more about what people are doing with the technology. Sometimes these are interim measures, what the real effects/changes are harder to get to.

Idea: nonprofit learn start up meet up in Bay Area?

Learnings: funding/how does funding community intersect or not with learning fast/iterate. Validating a learning process. Approaching it all as an Experiment. Failing FAST is good. Next Steps: go to Raeanne from Quilted who’s digging deeper into these issues (in next learning session).