Now write some code to make these executable specifications run.
The automation bit is actually optional: you can get lots of value out of BDD just from having the conversations. So especially when you start out with BDD, don't get too worried if you don't automate all your scenarios.
But if you do it right, and if you make sure your application has testability built in, this can really help streamline the development process.
There are two ways you can do this. Firstly, you can automate before you write the application. Obviously, the test will fail - that's how you know you haven't already built the feature (and that your tests work). Then build enough of the feature to make the executable specification pass.
This approach works really well when you have (or create) a well-defined API layer. The automation coding flows smoothly into a TDD process, resulting in very tight feedback loops.
We call this "outside-in development", and it's by far the fastest way of coding large projects that I know. But it does take skill and practice, and involves a lot more collaboration between developers and testers to make it work.
The second way is to automate the skeleton code, and fill in the gaps as you implement the feature. This is easier when you start out, and it works, but it doesn't give quite the spectacular results you get with the first approach.