Winning My Way to Weight Loss

Posted on by

You won’t change what you don’t track.

I’ve heard this phrase before but never put a lot of stock in it. After all most people won’t change what they do track, also. I think this is going to join my lexicon of great phrases. [1]

When I was a teenager I weighed 155 pounds sopping wet. I never had to work at it. I just had a very high metabolism and was athletic. In college I put on a few pounds but was generally pretty lean for my height, staying around 165-170. After I graduated, though, and when I started sitting on my butt for a living, I ballooned. At my heaviest I was 220.

For the past decade I have fluctuated between 205 and 220, occasionally getting down as low of 200 but rarely dropping below it. I’d like to be about 190. What has made this worse is my on-again, off-again fascination with physical exercise. I’ve always been athletic and played sports when I was younger but never could stand the idea of running on a tread mill.

A couple of years ago I started riding a bike more seriously in the summer and finally forced myself to join a gym for the off-days and winter wet. 4-5 days per week I’m there with some combination of weight training, elliptical and swimming. [2] My weight has stayed pretty steady at 205 but I never seem to drop below that.

See, I like to snack in the evenings. I have this sense that I eat fine all day and then in the evening, after the kids are in bed and watching a little tv, I snack. Mostly it is healthy stuff but I do like a cookie and a glass of milk. Anyway, if I could just stop snacking, I figured, I’d lose the weight. No amount of will power  seemed to work. I always gave in.

This weekend my wife introduced me to My Fitness Pal, an app and service that tracks exercise and diet. What works is that they have a massive trove of foods already in there so the pains of entering aren’t so bad. Saturday I started tracking and I can tell you that the reaction was instantaneous.

Suddenly I had no desire to snack in the evenings and even my meal choices were changing. [3] My desire to exercise improved, too, so I can eat what I want. It turns out my competitive streak took over. There’s a little number at the top of each day that tells you how many calories ahead (green!) or behind (red!) you are for the day. I’ll be damned if my numbers gonna be red!

I couldn’t believe how fast the change happened for me. Literally within hours I was thinking about my intake and looking for exercise opportunities. It will be interesting to see if I can keep this up but if so I bet I shed those extra 15 pounds in no time.

Once I master this game, I’ll have to raise the stakes. I’ll need that cholesterol counter to show me green and red.

—

[1] Two of my favorites are “Proper Prior Planning Prevents Piss Poor Performance”, the 7-Ps, and “Cash is King.”

[2] In the winter. In the summer it is a couple of days per week to supplement by three-time per week bike rides.

[3] I was right. The evening snacking was killing me.

Accounting Time Capsules

Posted on by

I always feel slightly nostalgic this time of year. Why? Because my accountant has free shredding week and I pull the old accounting records from the attic. During the process I glance through the files to make sure nothing was filed that I need to keep. In those files I see all kinds of goodies. Old employees I have such positive memories of. A sense that it really wasn’t that long ago that we all worked together. Channels we used to sell through and, because of the vendors and suppliers, a sense for people I haven’t talk to in a long time.

In some ways, those years felt more certain, our success more guaranteed. Now it feels more nebulous and harder to grasp. Reality, however, didn’t turn out that way and what we are working on now has way more potential than what we were working on then.

This year I get to review two years: 2005 and 2006. For some reason I have been keeping eight years back instead of the required seven. 2005 was a very rough year for my wife and me personally. In January of that year my wife’s father died suddenly and in February we lost our baby at 22 weeks pregnant. 2005 also was the year Infinity Softworks lost 75% of our revenue in six months, forcing me to lay off most of the staff and refocus with a tighter team. We went from 10 to 3 people during that time.

2006 was rosier. We were close to shipping our new education product, which at the time we thought was going to have great success. And my first daughter was born a year after we lost a son, one of my three happiest days on this planet. [1] Unfortunately business success was not there yet and navigating first-time fatherhood was difficult. Let’s just say I didn’t handle the mixed family and work responsibilities well. By the time the calendar hit 2007, though, it felt like we were at least on solid footing, at home and at the office [2].

These two years were especially important. They were transition years. Infinity Softworks was changing. I was changing. For the first time I was asking questions about why some businesses were successful and some weren’t. I was questioning the “this is the way it is done” party lines that had nearly driven Infinity Softworks out of business. My priorities were changing. In some ways, for the first time, my wife and I weren’t just two people living in the same house. With the birth of my daughter we were a family.

The years pass, of course. Seven since this time, to be exact. In a few weeks another year will go by the books. In a few weeks I will put 2013 in a box, where it will wait to be opened and its stories revealed, like some accounting time capsule, in 2020.

—

[1] The other being when my youngest daughter was born two years later and when my wife married me 13+ years ago.

[2] At home that proved true. At the office… another mirage.

6 Lessons From A Contract Development Job

Posted on by

Last week was insane. I don’t think I’ve worked so many hours in a long time. My conservative estimate is 85 hours alone with my business partner in for another 70 or more. We are working on a contract job — got to pay the bills some how as powerOne has become a labor of love — and it all came to a head last week with a deadline for today. We made our deadline. Why so many hours at the end? Because there were too few hours at the beginning.

We have never done much contract work before this past year, at least not stuff that isn’t calculator related or where I am closely guiding the development requirements. This year we have done two such projects. The one early in the year was extremely well specified. We knew exactly what we were responsible for, how they wanted it done, and had header files of everything we needed to interface with. While the coding was different in some ways from anything we had done before, the project was well defined and very straight-forward.

This project, though, was open-ended. We had a basic requirements list but not much was well defined. Even the requirements list was fluid. So here are a few things I learned from this project:

1. Force a refined requirements list. I shouldn’t have bid on a project that was quite so fluid but I did. It’s a start-up, they are moving fast, and the project was right up our alley. Plus, they had a two month window so I wanted to get started. So we did.

Honestly this wouldn’t have been such an issue if we would have had more domain knowledge. But this is one of the few times in my career I developed a product where I didn’t have a sense for the customer.

2. Mobile is not the web. This is one I knew but reinforced once again here. In essence the partner company said here’s the website; go play with it. I did a little but given that it wasn’t my domain expertise and the site was complicated, I didn’t play enough. When developing, every layer we peeled off the site showed even more complexity. I didn’t understand the full extent of code required and not sure I could have from “playing with the site.”

3. Specify, specify, specify. Which leads me to #3: I should have focused everyone on creating a specification right up front. What did we need? How many layers were there to the site? How would we simplify the entire site to fit the mobile paradigm? We thought we could do this as we went but that was a problem. We spent too many hours re-writing code and their designer spent way too many hours writing APIs for features we didn’t use.

I had a professor who once said that writing an app is 70% planning and 30% coding. What he didn’t say is that most of that 70% needs to happen up front. As I mentioned, normally not a problem as usually I write apps I understand inside and out. But when writing for someone else, especially in a domain I don’t know? More planning up front.

4. Someone must be in charge. There really wasn’t any one in charge of decision making and planning on a day-to-day basis, or more accurately it was shared. The CEO of the company we were developing for is really a sales guy, so feedback came late in the process or not at all. Mostly we were left to make our own decisions and sell them to the company, but it took us a while to get the hang of that. Luckily, the company CEO is a very reasonable person.

5. UI first or data first. Every app I have ever written started with the UI. We designed what we wanted it to look like, the features we wanted, and then built the models to match. I spent the first few weeks of this project completely frustrated because this project was the exact opposite and I didn’t realize that. In this case the data (because of the web app) was well-defined and we should have started with the models and then built the UI from that. We started moving forward once we figured this out.

6. Simplify. I preach this over and over again for our own consumption. The same is true for contract jobs. There is never a UI or data model that can’t be simplified further. Again, so thankful the company’s CEO was so reasonable. I do hope they take these lessons and bring them back to the web.

Outside of the intense process at the end, it turned out to be a decent development project. I hope we can get back to working on powerOne and Equals, though, and that we can figure out how to turn those into sustaining businesses. I really don’t like writing code for other people’s ideas.

How Do We Know When We Have a Minimum Viable Product?

Posted on by

I was at a breakfast meeting yesterday and we got to talking about minimum viable product (MVP). I’ve written about this before, basically saying how speed of development and MVP are not synonymous. But the question arose: how do we know when we have a minimum viable product?

Before I answer that question, though, I want to make sure we all understand this incredibly important concept. A minimum viable product is the least development you can do to give your potential customers the idea of what you are trying to accomplish, what benefits this service/product might bring to them, and give you a feel for the revenues and costs associated with delivering the service/product. The point of MVP is to get those of us who are inclined to sit around the office and develop apps out of the office talking to customers.

Dropbox famously built their MVP as a video. I’ve seen paper reproductions and I’ve seen code. Sometimes wireframes work or a nicely mocked up PowerPoint presentation. Every one of these can get the idea across and get a conversation started. In fact I could easily argue that the less code you write the better off you are. [1]

It’s important to understand that most people can’t imagine what you are imagining. They need to see it or touch it to truly get it. And that’s why words on a page or a concept in speech is simply not enough. Physical is better. The decision about how to get that across to a customer, though, is up to you.

When we started working on an MVP for Equals we decided we needed to write code. The concept — writing a note that can tell the difference between text and numbers, performing any mathematics automatically — was hard to imagine. We felt it was important to show that ability so we started with an MVP that did just that and over the course of months refined its capabilities.

We also realized that there were a number of other things we wanted to test as well with customers. Would sharing be of interest? Would being able to send things to third-parties like Evernote, Twitter and Facebook be important? What about collaboration? History? Integrated data?

Some of these things were natural offshoots so we didn’t need to develop them. Once people understood sharing the idea of collaboration was a natural extension, very easy to discuss. Some we could put screenshots in place that simulated the look-and-feel but didn’t actually function. I didn’t have to build Evernote, Twitter and Facebook integration. Showing a table with those options was enough. When we developed the first Equals MVP we included no text formatting. We talked to potential customers about the idea but found that it didn’t stimulate a conversation. So we added functioning code. [2]

Once again, back to the original question: how do we know when we have a minimum viable product? We know when we have a hint of all the features we want to get a reaction to from the customer. Those features need not be complete and in many cases they don’t even need to be functioning. But they do need to spark a conversation.

After all, the whole point of the MVP is to get a sense from customers as to whether we are on the right track or not.

—

[1] This goes especially for non-developers. Stop asking people if they’ll write an app for you based on an idea. Mock the thing up in PowerPoint or Keynote using a tool like Keynotopia and go get customer feedback. That’s a heck of a lot cheaper than writing code.

[2] We also needed to prove we could do it in a cross-platform way.

Slugball

Posted on by

I was at a conference in Bend, Oregon, and met this guy Matt who was working on a sports email newsletter. I have followed sports since I was a kid. At one point I knew just about everything one could know about every player on every team.

But now I don’t have that kind of time. I get Cleveland Indians, Browns and Cavs news during the day and keep up with that. In the evenings I usually glance through the headlines at espn.com. But that’s it.

So when I met Matt and he told me he was working on a daily sports email newsletter I was intrigued. We talked about the idea for a bit: highlighting the non-obvious stories, the human interest ones, the ones ESPN just doesn’t report. I mentioned the story last year about the NFL player who blasted the Maryland lawmaker for being critical of another pro football player’s pro-gay stance, which never was mentioned on espn.com. He agreed that this is the kind of story he is interested in.

A couple of weeks ago he released his first issue. I thought I’d try it for a while and if it wasn’t to my liking, I’d unsubscribe.

I’m happy to say that the stories he reports have been incredible. Each issue includes about six articles and I’m happy to say that sometimes every one of them is too interesting to pass up. Monday’s issue had a story on a double murder in Brazil over a soccer game, how The Ohio State marching band is putting the screws to the competition, why kids still love baseball, and a story about a Japanese pitcher who had won 30 straight ball games. The best in that issue, though, was a story about a Nigerian basketball player who was fascinated by snow. And this was only Monday!

Enough of me going on about it. Check out Slugball. It’s an incredible dose of daily sports human interest stories right in your email box.