RWSEfE

Real World Software Engineering for Entrepreneurs (A Startup Accelerator)
Preparing for your first panel - Class Three - June 1, 2011


From the instructors, Scott Russell and Todd Sedano

It's normal to be apprehensive about your first panel. It's not clear where you are headed with your idea, and you haven't had a chance to validate it with the marketplace. You are focused in the coding trenches trying to get something to work, it's time to pop out and see what the market thinks of your idea.

When you meet with the panel, you've got to tell people how it is supposed to work. You are looking for their feedback reaction. Then you will learn how far off you are. Embrace expectation failure, you need this feedback.

The panel knows that your product is "raw" and not finished.

If you think you know who your target customer is, put that forward. If you aren't certain, hazard a bold specific guess. "Our customer is film lovers in their early 20's." If you know the makeup of the panel, then you can see if the panel is your target customer. When you are speaking to an intellectual group in their 40's, don't be surprised if they don't resonate with a product geared for Lady Gaga music fans.

When presenting your product, don't focus on what the product does, but what problem you are trying to solve. Be provocative. Tell them it cures cancer. If they don't think your product does that, find out why. Find out how you are missing the mark. If you were selling an Recreational Vehicle (RV), you don't sell the customer on the miles per gallon or the capacity of the septic tank, you sell them on the vision: imagine being at the lake fishing with your family.

Put on your sales hat and BS about what the product does. Don't tell them what the product is going to go. Avoid "we working towards a release one where ....." and "we think that the nominal market will be." Instead be bold and clear. "Our product is facebook for the medical community." Be laser focused. Be specific about the key core functionality. You aren't going to release a product that works on every phone. "For the first release, our product works on the iPhone platform." If people want more and more features, it's ok to delay the features. You don't have an infinite amount of time and money to build everything.

The common user won't understand technology. You can explain what it is and what it will do for them, but don't get lost in Acromania. "We've done the hard work to build something special." It was tough to do, but you are making it easy for them. It's a defensible asset.

Consider how you will end your presentation. What do you want from the panel? Ask them a question. You have just spent six minutes of your valuable time presenting to this panel, what is your ask?
ask the panel a question.


We've asked the teams to consider their strategy for their first panel. Here is a sample of their thoughts.

Team Coach Potatoes (Andrew Steele, Anooj Vagadia, Patrick Baumann, Henry Fung)
As a development team working on an as yet unreleased product, we are looking to get as much out of Wednesday’s panel as possible. Most importantly, we will be trying to assess the feasibility of our idea and its potential worth. Part of our presentation to the panel will consist of a demo of our current features and discussion of upcoming features. We hope to gather feedback regarding which features are of value, which are not and which would be worth spending money to have. Our application is targeted specifically towards individuals who are active, which may affect the objectivity of the panel’s feedback if they are not active themselves. However, it is still important to gather feedback from non-athletes to determine if our application will be appealing or motivating to them. If the application is not appealing, we will ask if there are changes which can be made to make it more so. We look forward to Wednesday’s opportunity.

Team Four of a Kind (Alan Mak, Kevin Tsai, Matthew Lanken, Paul Wong)
Our main strategy for the 4th week pitch is to focus on getting the panelists more involved with the theme and vision of the product. By doing so, the panelists would get a sense of why there is a need to use the product. Several past criticisms suggest pitches didn’t have a direct and exaggerative tone suitable for marketing, and were instead received as a simple explanation of the product. During our pitch, we plan to emphasize the magnitude and greatness of the application while being more direct in our pitch towards the panel. We plan to pitch to them as if they were the ideal target customers, and why they need to use the application. Aside from involving panelists with our tone, we will also introduce a few interactive gimmicks such as distribute four playable demos of the application, a tutorial that will guide users through a quick workout and allow them to follow along, and props to enhance the theme of fitness and quick workouts. We also plan to take this opportunity to get user feedback and weigh some of the other selling points of the application such as the virtual buddy and achievements.

Team Opinionize (Gaurav Sinha, Rob Engel, Phil Melzer, Vinay Prasad)
Our strategy in the panel pitch next week is to get more feedback about the product, its use cases and reasons why people will buy or not buy it. The other important part of our strategy is to make the most of the experience the panel brings in the room.

We need to understand our target customers. We believe that it could be anyone who has the problem of categorizing large amounts of data but we want to narrow down on our users. Adam mentioned that our probable users could be geeks who use / edit Wikipedia articles. For this reason, we will present a case for members in the panel to use the product, based on our knowledge of their interests. Their feedback will be valuable in determining whether the product is for everyone or not.

We want to get feedback about what makes the product viral? And why? The panel consists of people who have the experience in the market and can judge what is going to hit or what is not.

We plan to keep our description of the product at a very high level and at the same time we would explain the concept in simple terms, which a non-geeky person can understand. Keeping the description at a high level allows room for improvement based on panel feedback. At the same time we would like to explain the concept with daily life problems as examples so that its clear to the audience. We plan to do a live demo of Opinionize with these examples, which would help the panel get a feel of the product.

Craftsmanship class 2

Question for group: what did you like about the kata?
Random drawing on Kata implementation
Random drawing on maiden speech
Question for the group: how did the reading about estimation of our competance relate to this course?


Responses include
The kata was simple enough to let us explore our tools. Never did TDD in C++ before so it gave me time to try that out. I also liked it because it was complex enough to allow us to try complex ideas like recursion.
The Kata had the right level of difficulty. It was a good programming (algorithms) exercise and a good TDD exercise
Helped to start working towards the goal "refresh 'java programming skills' "
It helped me learn a new testing framework and helped get me back into programming mode after taking a few months break.
Learning TDD in java
Program was simple so I could concentrate on the practice
Got me introduced to the testing framework
Once setup was completed, it showed my that TDD is language/platform agnostic, which should be obvious but was surprising
Learning how to do it in java using eclipse, it was easy
first time doing TDD in Java
learned how to use git with eclipse

Two more weeks until craftmanship course starts

I must be having the butterfly jitters before offering a new course, Special Topics Seminar: Craft of Software Development. I sat down with a google document to review everything that I wanted to do with the course. In a moment of feeling that I must have been missing something, I reviewed my original blog post about the idea. To my surprise, the ideas in my original blog post were consistent with my current ideas and still at the heart of the course design.

I'm using Keith Johnstone as an inspiration for this course. While I have some course structure, I want to be flexible with the delivery and reflect after each session on how the course can be better serving this particular group of students. I'm also wanting to try some crazy in class exercises. At times, I feel that actors getting on stage is an easier art form to work with than software developers writing code. Perhaps I'd feel differently if everyone knew the same programming languages.

Sitemap Powerpoint presentation

I tried an experimental presentation technique today, which I call "Sitemap Presentation."

When I was asked to do the talk "Entrepreneurial Opportunities in Silicon Valley" for Carnegie Mellon University at the Pittsburgh campus, I drew out on paper my talk outline. My drawing reminded me of Kent Beck's notes when he was presenting at Rails Conf 2008 (?) -- its much like his drawings at the beginning of his book.

When I was creating the slides, I wanted the ability to hop around to different parts of my presentation. Yes, I could do one ordering of the topics, but I wanted to be flexible with my talk and respond to what the audience wanted. So I scanned in my diagram and used the diagram as my agenda slide. I duplicated the diagram throughout the presentation. I found that the drawing was more to my liking. I've never been fond of doing an agenda slide, they always feel so boring, but this really livened it up and allowed me to see quickly where we were headed.

In my ideal version, each part of the sitemap would be clickable. Thus I'd have a title slide followed by an agenda slide. Whenever I clicked anywhere on my diagram, it would go off on that thread and then return to the agenda slide. If I clicked on a different part of the agenda, it would take on a different thread. I'll have to figure out how to do this in powerpoint / keynote.

`load_missing_constant': uninitialized constant Debugger::CommandProcessor

To make a long story short, I've been having some development configuration issues. I've switched to rvm and bundler, but sometimes my old gems bit me when I'm not expecting it.

While trying to restore sanity to my development environment, I came across this error.
"`load_missing_constant': uninitialized constant Debugger::CommandProcessor "

In my Gemfile, I was specifying:
gem 'ruby-debug'
gem 'ruby-debug-base'
gem 'ruby-debug-ide'

According to this thread, http://youtrack.jetbrains.net/issue/RUBY-5341, if I'm using RubyMine, I do not need to include ruby-debug which is for the command line.

My new Gemfile includes just
gem 'ruby-debug-base'
gem 'ruby-debug-ide'


Also on this journey, I decided to uninstall all my old system gems. I was able to do this with opening a new terminal window, rvm use system, gem list --local, sudo gem uninstall GEMNAME. I was able to get rid of most of them this way, but a few were still lingering around. I did an gem env and removed some directories including:

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8
/Library/Ruby/Gems/1.8



I'm still on 10.5

What I learned at RailsConf 2010 presentation

See this pdf

Software Engineering Craft (or Software Engineering as a performance art)

Experiment with full time students this summer to explore this topic.

In a language and framework of their choice, have students select a short project to build, ie a blog website, or twitter client mobile application. Include testing. In the first session, build the project. (Time it.) Repeat again. Repeat again. Repeat again. After each session reflect on what you learned. Was there insights about the IDE? Where there key command short cuts? Do your test cases get better from defects from previous sessions, or do they get worse because of short cuts? Is there an aspect of the technology that you are deficient in that requires additional practice? (Katana example) Look for trends across the student population.

Based upon trends across the student population, identify further areas of practice.

Try same experiment with paired programming.

http://github.com/edgecase/ruby_koans

Inspiration: improv - learning scene work or singing a song from scratch. Take an impossible task and break into small concrete steps. Slowly build upon the steps to reach the goal. Sometimes explore the concept of each step with positive and negative examples.

Inspiration: Katana for TDD

Inspiration: Learning to play the piano. Strength building exercises. The whole point of the exercise is to build up . Much like dance where there are patterns, technique and skill aspects to a class. The patterns make learning dancing fun and motivate the student to keep going. Playing a song is rewarding. Working on skill is tedious but makes the fun stuff more accessible and easier to accomplish.


http://rubyquiz.com/
Ruby Koans - http://github.com/edgecase/ruby_koans


Javascript learning - http://ejohn.org/apps/learn