It’s okay if you don’t know exactly where you’re going  – because things are always changing – just so long as you’re focused on the Right Things.

BUT, this is really hard at a startup precisely because everything is always changing.

It’s essential that your developers are okay with these points. It drives me a little crazy every time I hear a startup developer complain that things are changing all the time. Well… what’d ya expect?

BUT… in their defense, I’ve seen many a startup do a truly horrible job managing their developers so that every ounce of chaos comes flooding down on them to the point where they can’t get a thing done.

This often plays out something like this.

The Ineffective Way to Build Your Startup’s Product

Founder: We need to get this “MVP” out the door to start bringing in revenue if we’re going to survive. How long will it take you to build this?

Dev: I can do it in 2 weeks.

Founder: Great, go for it.

Two days later…

Founder: I just spoke with some potential investors and they said we need to do X if we want to raise money. Do that instead. How long will it take you to do that?

Dev: Well, if I stop working on the MVP…

Read More…..

You’ve got your vision of what you want to build.

You’ve also got a ton of unknowns and uncertainty. You know you can’t just go build it and hope they will come. You have to do it iteratively. Put a little bit out there, see how people react, figure out what to do next.

But where do you start? How much is enough to start getting feedback?

Josh Seiden gave this awesome talk at Boston’s Lean Startup Circle on replacing requirements with hypotheses. And it occurred to me that what he’s really talking about is hypothesis-driven development, which I love.

In Agile, we drive our development with tests. We say, “okay, I know what the product needs to do, so let me write the test first.” It’s an automatic check. If I accidentally develop the feature incorrectly, the test will fail and I’ll get immediate feedback that the feature isn’t ready yet.

But what about in a startup where we’ve only got guesses for what the product should do? Then the tests should not be whether features are implemented correctly. Who cares if nobody wants them?

What we do care about is creating a successful business. So those tests aren’t for if the product works, they’re for whether it’s the right product. Now we’ve got an automated check. We don’t waste our time & money building something until we’ve validated it’s the right thing to build.

Read More…..

MIT’s Entrepreneurship Center asked me to give an Agile Product Management workshop for their Hacking IAP course. The course is a special seminar in management they’re doing for MIT student entrepreneurs. It takes place over the IAP (January) term and is open to all MIT students that have startups already underway.

The first week of the course is a series of guest lectures from industry experts on how to get shit done (that’s where I come in). After that, the course serves as a mini-accelerator with students applying what they’ve learned to their startups and receiving mentoring from myself and the other lecturers. The course concludes with a demo day at the end of the term – which I can’t wait to see!

Here are my slides – I actually beefed this up a little for SlideShare, adding some bullet points for the key talking points (I know, bullet points suck – but otherwise all you have are pictures). Hope you enjoy!

Maybe it’s all the time I spend with startups, but while I strongly value Scrum’s ideas behind self-organizing teams & continual feedback – I can’t help but feel Kanban represents the next level of agility, giving us more flexibility and capitalizing on the lessons we’ve learned from Lean.

Scrum

A lot of people tend to think Agile means Scrum – you know how it goes: