Spaghetti or lasagna? What about your code? According to Conway's law, your business and your code have more in common than you might think. Break bad dependencies.
A friend of mine from when I was growing up is a true blue professional hacker for the US military. He gets paid to hack security software. Specifically, he writes software which figures out how other security software works. He figures out what the requirements are. He prods the software, notes down its behaviors, and then uses that feedback to construct more ideas for tests. Based on the requirements he gleans, his team can build exactly the same thing from scratch, if they decide that’s what they want to. Geeks call this technique reverse engineering.
You can take the same approach when trying to sell a new product. While it might not always feel pleasant, the market tells you what it thinks by giving you feedback. (No feedback is feedback too.) I’ve put up offers which seemed like they’d be interesting for my target audience, but they didn’t sell. Certainly made me feel like a doofus, although it clearly wasn’t fatal, since I’m writing to you about it! They attracted attention and freebie downloads successfully, but for some reason, people didn’t feel motivated to buy.
Keep on truckin’. If you don’t have a selling offer yet, keep prototyping new products and putting them up for sale where you think your market hangs out. Keep talking to them.
You can do this systematically by planning to launch a new offer every week. It doesn’t need to be perfect with a massive campaign and a perfect website. It just needs to attractive to a niche and buyable.
Once you are at the stage that people are buying, then go ahead and work outwards from there. Your first few sales, while they might seem insignificant, are a crucial step forwards. They give you the basis for reverse engineering who buys in your market and why they buy. You can feed this information back into your product and your marketing.
If you don’t have buyers yet, that is your first bottleneck. Figure out how to solve that problem first. Once you have customers, then you have your work laid out for you.
There’s a specific agile tool which I think every early-stage product team should use, regardless of whether they’re following the Lean Startup methodology. Lean Startup drew its roots from agile software development. Eric Reis added Steve Blank’s idea of customer development to agile. Assuming we aren’t talking about re-reading Eric Reis’ book for the 17th time, the best Lean Startup tool is the dogeared post-it.
What? Why not some kind of fancy-shmancy online tool that defines, builds, and releases your product? In your sleep. There’s lots of those around. < grin >
Post-Its are placeholders for team discussions. Invented by accident at 3M, having slips of paper with adhesive turned out to be a fantastic tool for organizing ideas.
This harks back to the old Class-Responsibility-Collaboration (CRC) approach introduced in the early days of object oriented software design. Post-its and index cards helped create the internal design of a larger software program. If you don’t understand the problem domain well enough, then it’s hard to design good, clean software. Post-its allowed developers to note that they need to discuss something in detail at a later date. Once developers were ready, they huddled around a problem. They dissected the problem into sub-components. They formulated a solid hypothesis about the best way to solve a technical problem.
Over the years, software teams have attempted to create software versions of the same experience. There are lots of tools which approximate this effect. Of the ones which I think are probably as close as you can get with software: Jira and PivotalTracker.
Unfortunately, as soon as you get a team in front of computer screens you lose a lot of information. This holds true regardless of whether they are in the same room or in different time zones.
Here’s a handful of ways you can use Post-Its for your product development:
If your goal with Lean Startup is to de-risk a product idea as soon as possible, you need to identify where you are going. To do that quickly, you need “signal”. Signal will help you achieve that faster.
A smattering of post-its on a physical wall are a true “information radiator”. Anyone and everyone can jump in, comment, or move the post-its around. This means you engage everyone’s head.
Post-Its are a thinking tool. They help your team think clearly about
With Post-Its, it’s not really about using post-its themselves. Using PostIts means that you interact more effectively: in-person, on-location, face-to-face.
As you can see, the lack of structure which post its give you, help you to discover and learn about your problem much faster. By using a software tool, you are hard-wiring in assumptions which may not be true for you or your product.
Imagine that’s what you hear as you jump up and down on the biggest physical or virtual stage you can afford on Launch Day.
It’s probably the worst possible outcome for a product launch. You and your team have slaved away for months. You put finishing touches on the product, the marketing, and even splurging on an extra super-duper haircut for you.
Yet, you hear no response. The prospects who you thought would be clamoring…aren’t.
Once you dig into it, it turns out that they were just politely telling you what you wanted to hear. Except you’ve already spent months or years worth of your life polishing your product idea. It turned out to be a turd.
To make it worse, you could have just talked to the audience before building anything. You could have found this out at the beginning. At least you could have been building something people wanted. Something they’d be excited to buy. To pay for.
Presenting…the extreme product launch.
In software development, Extreme Programming (XP) is a style of programming. XP promotes coding with courage. Developers can make changes to large chunks of code, because they have tests to prove a change is ok. Before writing code, they write tests. Those tests make sure the code works as expected, regardless of how the code ends up looking.
It’s a special technique called test driven development. How about applying the same system building approach to building a business system?
Extreme product launches take the same idea and applying to a fledgling business. The main goal of a business is to make money. Before you start building up a technology or information business, try to sell your product first. If you prove you can generate cash flow, you have much greater certainty that your business will work. You don’t really need a product to prove that.
Even though an extreme product launch may sound like a new idea, it isn’t. There are many sites which promote selling a product before you have it. Kickstarter for products. LeanPub for books. Enroll.io for courses. Thanks to the take-down of private company funding regulations in the US, there’s even websites for funding businesses which don’t exist yet.
In order to be able to sell up front, you need to figure out:
You don’t need a product to do that.
In fact, at this early stage, you DON’T want to be writing code. If you don’t know what your prospects want, you’re just gold plating a bunch of unproven assumptions into your product. Which has a good chance of turning out to be useless. To your intended audience.
And it doesn’t take much. Just talk to them. They don’t bite.
If you want any help, schedule a call with me at https://www.sohelpful.me/agilelasagna. I don’t bite either.