When we hired a new CTO at Valore, we rolled out agile/scrum with our product and engineering teams. We had been in the waterfall dark ages. We predictably experienced every bad outcomes one could expect from a misaligned development process. It took some time for the team to understand it, get comfortable with it, and realize the many benefits of it.
A sampling of the many benefits we have experienced from adopting scrum include: Continue reading “Implementing scrum for non-software teams”
Why don’t business people practice?
Sports and business are always compared. There are an endless number of analogies used every day – teams, winning and losing, star players, competitors, etc. The comparison holds, for the most part. Except for practice. Why?
Athletes at all levels know that they will need to practice their ass off to compete at the highest level. Daily images of athletes toiling away in the anonymity of the empty practice field or gym stream over the airwaves to us. Continue reading “Practice”
Sticking to new habits is always hard.
I often find myself experimenting with new tactics to increase my learning, be more productive, or save myself time (so I can focus on more ‘valuable’ things). Notice, I don’t call them habits. They are deliberately experiments. Only if they prove effective would I continue to focus on them, ultimately with the goal to make them habits. Continue reading “coach.me”
We are now about five months into our transition to Scrum. Embarking on the experience as a Product Owner has been awesome. I recently came across a useful graphic that outlines the skills (and there are many) that make a good product owner.
This is a good summary. I would add Authority to the chart (but that messes up the layout of the poster, so I’m sure the creator had to make some hard decisions). Authority is a more nuanced form of leadership, in my opinion, but it is important to call it out on its own. Authority comes from your domain expertise, and the way you carry yourself with the dev team and the rest of the organization. You earn this, you don’t just ‘have it.’ It’s a hard thing to master, but it is instrumental to your success as a PO.
It has now officially been two months since I started work. I have no idea where the time has gone, but it has gone faster than I ever expected. As I reflected on the first two months this past weekend, I thought a lot about the things that I have learned since I started.
Coming from the world of theory, frameworks and supposition (business school), I have found the transition equal parts exciting and frustrating. Most of the frustration stems from the fact that the real world never quite plays out the way the theories suggest they will. This is a pretty obvious statement, but it is still something I took for granted coming back to the real world of a startup and being responsible for developing, marketing and launching a new product in just two months. In that light, a few key takeaways so far…
1. Don’t assume people understand, but build it so they can — Communicating with users, even if they are early beta testers (often friends), requires crisp communication. People are so inundated with new things, particularly on the web, with new products and services, that it is critical to refine how you articulate the product and its benefits in as clear and concise a manner as possible. Don’t assume people will “get it,” but then do everything you can to make the product simple, intuitive and of clear value to the user.
2. Minimally Viable Products (MVPs) doesn’t mean it’s easy — A lot of chatter is out there about lean startup methodology (@LsmFatso) and Eric Ries (@ericries) is doing great work in creating a movement around capitally efficient, user-focused companies. A crucial part of the theory is the idea of the MVP. The name is a bit of a misnomer and can lull first time entrepreneurs into a sense of comfort. Just because it is minimally viable does not mean it is easy! In fact, building a product that is engaging and useful for users is still really, really hard and it is important to put a great product out at the start. A product is not an MVP based on how much work or effort you put into getting it ready for launch to users. It is Minimally Viable because once you launch, you MUST continue to iterate and improve based on user feedback and rigorous analytical testing, so by default the first product should be the worst version (i.e. least viable) that you ever have. Don’t get tricked by the name! Continue reading “Theories Applied”
newmanea 