The remarkable thing about your mental life is that you are rarely ever stumped.” – Daniel Kahneman It’s Thursday morning. You settle into your office chair, you crack open your laptop, you take a…
Great posting from Product Talk by Teresa Torres!
Teresa discussed this in person over great beer and refreshments on Wednesday, August 14, 2013 Startup Product Talks meetup at Atlassian http://bit.ly/1e8Yr72
Teresa is also speaking on Friday, October 11, 2013 Startup Product Summit SF2! Register today for best price! http://bit.ly/11J59AG
Startup Product Summit SF2 is one event during Product Weekend San Francisco, starting with trainings on Thursday, Summit on Friday followed by AfterParty, then Product Camp San Francisco on Saturday all at historic Broadway Studios! Follow blog to stay updated at http://startupproduct.com
See on teresatorres.com
—>NOTE: This is a DIGITAL EVENT at your location on your device where-ever you are!
The Agile Business Gap describes the methodology gap between that exists between the origins of an idea or a market insight and the creation of an initial (and ongoing) product backlog of user stories. At it’s core the Agile approaches that we see are software development focused and in most cases anything that is beyond the boundaries of the Product Backlog and a release is largely ignored by any of the Agile methodologies.
“I’m looking forward to discussing how we have applied components of our Product Development Framework to the Agile Business Gap, in a way that embraces the core philosophies of the Agile approach,” states Nick.
NOTE: DAY & TIME!
Monday, April 22, 2013 at the simultaneous times of 3:00 PM PT, 6:00 PM EDT in New York, and 8:00 AM AEST Tuesday, April 23 in Sydney, Australia
Background resources: http://bit.ly/YXRSko
Mark your calendar with the correct time: http://bit.ly/173wtb8
Follow for reminders: http://bit.ly/nbw9Yr
Curated Content: http://bit.ly/TV4Dsp
Questions for Discussion:
PreQ: Please introduce yourself, where you are tweeting from & your involvement with #prodmgmt #prodmgmttalk
Q1 What is the Agile Business Gap?
Q2 Where do you see this Agile Business Gap being a problem?
Q3 Is there a way of closing the Agile Business Gap in larger businesses?
Q4 So what do product managers actually have to do to bridge the Agile Business Gap?
Q5 How does a business start closing the Agile Business Gap?
Q6 What barriers do you see to being able to
close the Agile Business Gap effectively?
See on www.meetup.com
Poornima says, “To guarantee that people will love the products you build, you need a process! I’d like to share the process I’ve been using and refining at all my startups: Mint.com, BizeeBee, and Femgineer. I know that sharing my process will help others in the Startup Product and Global Product Talks communities, who are just as passionate about building products as I am!”
Participants are welcome to listen live at http://www.blogtalkradio.com/prodmgmttalk, call in to talk on the show (323) 927-2957 and to participate on Twitter by following @ProdMgmtTalk and tweeting using the hashtag #ProdMgmtTalk.
From Poornima’s presentation at Startup Product Summit SF, Feb 7, 2013
Livescribed by Stefan Aronsen @sfintercom
By Michelle Sun
Here are the notes for the Roadmapping and Execution Lightning Talks and Panel at Startup Product Summit SF. Omissions and errors are mine (please let me know if you find any, thank you!), credit for the wisdom is entirely the speakers’.
- Product manager’s role is to capture, communicate and distill product ideas, and mediate between business stakeholders and makers.
- When building a product, pick two out of the three: quickly, correctly, cheaply. Joe later mentioned on Twitter that he would pick quickly and correctly, as paying for quality is no brainer.
- “Want to increase innovation? Lower the cost of failure” – Joi Ito
- Empower every developer to commit things to the product through non-blocking development (NBD).
- Advocate the move to 100% asynchronous communication because current approach is broken (needs human input to track reality) and remote teams are becoming more common.
“Raw Agile: Eating Your Own Dog Food” – Nick Muldoon, Agile Program Manager, Twitter
- Twitter does dog-fooding by allowing developers deploy to internal server. Dog-fooding allows:
- gathering real data from real (though internal) users.
- increases incentive to produce quality shipped code.
- better feedback. He found that feedback in dog-fooding environment is generally more constructive.
- keeps momentum through a positive reinforcing loop of continuous deployment and feedback. The team gets 50-100 feedback from internal users each day.
- How to decipher and sift through the volume of feedback. Look at only the “love” feedback, then all the “hate”, then discard the middle, categorize and show to the whole team.
- Other important aspects in dog-fooding:
- Automation. Allow deploy more frequently especially internally. ”On any commit, deploy internally.” Avoid accumulating technical debt.
- Visibility. Record progress and share on a wiki.
- Speed. Minimize cycle time (from to do to in progress, to done).
Best Practices for Architecting Your App to Ship Fast and Scale Rapidly” – Solomon Hykes, Founder & CEO, dotCloud
- 3 things to aim for in architecting your app: speed (continuous deployment), scale, future-proofing (be prepared for things moving very fast, avoid bottleneck and need to refactor when adding every new feature).
- What are the patterns/strategies in getting to these three goals?
- Be aware of trade-offs. There is no silver bullet; always trade-offs and prioritization.
- Trade-offs evolve over time. Priorities change. Be aware of assumptions and revisit them from time to time.
- Trade-offs differ from team to team. Be aware of bias in different teams. Always keep ownership of key decisions.
- Put yourself in a position where you are embarrassed, and things are going to happen faster.
“Rocket Powered Bicycles: Avoiding Over and Under Engineering your Product” – Chris Burnor, Co-Founder & CTO, GroupTie & Curator, StartupDigest
- A product connects business priorities with user experience.
- Proposes that instead of Minimum Viable Product (MVP), think about Product: Viable Minimum (PVM). Focus on viability.
- A scientific method to approaching product roadmapping.
- Idea: think about business priorities, user experience. Do not let technical decisions drive your product. Let product drive your technical decisions.
- Test: Viability of the solution is whether it solves the problem it’s setting out to solve. Determine what level of viability is suitable in different stages: GroupTie’s first viable minimum was a keynote presentation that was sent to potential customers.
Scale of tests will vary. Lack of big tests means the lack of breakout growth/ideas, lack of small tests means the team is doing too much.
- Conclusion: Debriefing phase is vital, share test results with the team and learn what it means to the idea. Testing without debriefing is like “talking without listening” in a conversation.
- An unusual example of a PVM is Apple. Product first: cares about user experience and business priorities. Viability second: it just works. Minimalism third: wait till a technology is ripe before adding to the product (no LTE for a long time, no RFID).
Notes on other panels:
About The Author
Michelle Sun is a product enthusiast and python developer. She worked at Bump Technologies as a Product Data Analyst and graduated from the inaugural class of Hackbright Academy. Prior to Hackbright, she founded a mobile loyalty startup. She began her career as an investment research analyst. When she is not busy coding away these days, she enjoys blogging, practicing vinyasa yoga and reading about behavioral psychology. Follow her on Twitter at @michellelsun and her blog.